Załącznik nr 9 do SIWZ Opis Przedmiotu Zamówienia

Transkrypt

Dla rozwoju infrastruktury i środowiska
Załącznik nr 9 do SIWZ
Opis Przedmiotu Zamówienia
System informatyczny do wizualizacji i pre-analizy wyników modeli numerycznych
Opracowanie:
1. Teresa Zawiślak
2. Mateusz Barczyk
3. Rafał Kielar
Strona 1 z 33
Słownik
ALADIN – model NWP
CAPE – (ang. ConvectivePotentialAvailableEnergy) - energia potencjalna dostępna konwekcji,
jednostka [J/kg]
COSMO – model NWP (także nazwa konsorcjum użytkowników tego modelu)
ECMWF – European Centre for Medium-Range Weather Forecasts
GRIB, GRIB2 – otwarty format zapisu danych meteorologicznych, zalecany przez Światową
Organizację Meteorologiczną (WMO), w dalszej części dokumentu, jeśli nie zostało to
wyraźnie rozróżnione, wspomnienie formatu grib dotyczyć będzie zarówno formatów grib jak
i grib2
IMGW-PIB Instytut Meteorologii i Gospodarki Wodnej – Państwowy Instytut Badawczy
INCA-PL – model nowcastingu pól meteorologicznych (w tym opadu) użytkowany w IMGW-PIB
MSL – (ang. Mean Sea Level) – poziom morza, jednostka [mb]
NCEP – National Centers for Environmental Prediction
LEADS – operacyjny system zarządzania danymi meteorologicznymi, stosowany w IMGW-PIB
LTS – system przetwarzana i prezentacji danych z systemu detekcji wyładowań, stosowany
w IMGW-PIB
NWP – (ang. Numerical Weather Prediction) – numeryczny model pogody (np. Cosmo, Aladin,
GFS).
PSHM – Państwowa Służba Hydrologiczno Meteorologiczna IMGW-PIB
SFC – (ang. Surface Level) poziom gruntu, jednostka [mb]
SHR – (ang. Wind Shear) – wektor ścinania wiatru (zwany czasem uskokiem wiatru), jednostka
[m/s].
SRH – (ang. Storm Relative Helicity) – skrętność atmosfery względem wektora przemieszczania
burzy, jednostka [m2/s2]
SYNOP – format zapisu obserwacji meteorologicznych ze stacji synoptycznych
n.p.g – nad poziomem gruntu (odpowiednik ang. a.g.l. – above ground level)
Strona 2 z 33
Spis treści
I. Wstęp
II. Założenia ogólne
III. Moduły dostarczanej aplikacji
IV. Dane wejściowe i wyjściowe
V. Wymagania w stosunku do wykonawcy
VI. Szczegółowy opis podzadań
1. Moduł – Edytowanie pól wynikowych modeli numerycznych w celu ich korekty
2. Moduł – Przeliczanie pól modelowych
VII. Harmonogram prac
VIII. Warsztaty dla pracowników Zamawiającego
IX. Zakres wsparcia technicznego
X.
Wymagania ogólne
Załączniki:
Załącznik nr 1 – Interfejsu
Załącznik nr 2 – Moduł modyfikacji pola modelowego
Załącznik nr 3 – Moduł: przeliczanie pól modelowych
Załącznik nr 4 – Moduł integracyjny. Załączniki 4.1 – 4.4.
Załącznik nr 5 - Standardy IT stosowane w IMGW-PIB
Strona 3 z 33
I. WSTĘP
Zadaniem systemu będzie bezpośrednie wsparcie synoptyka w procesie przygotowania,
nadzorowania i aktualizacji prognoz.
Niezbędnym i podstawowym elementem pracy współczesnego synoptyka jest analiza wyników
numerycznych modeli prognoz pogody. Mnogość informacji, które należy zweryfikować w procesie
opracowywania synoptycznej prognozy pogody wymaga narzędzi, które ułatwią pre-analizę
wyników modeli, ich modyfikację w celu usprawnienia procesu powstania produktu końcowego.
System musi być zbudowany w architekturze wielowarstwowej, w której wyodrębnione będą, co
najmniej następujące obszary: Prezentacji, Logiki biznesowej (obejmuje przetwarzanie danych oraz
usługi) i Magazyny danych. Poszczególne obszary logiczne aplikacji będą wyodrębnione do
osobnych komponentów, które będą mogły być umieszczone na osobnych komponentach
infrastruktury fizycznej.
System musi być w pełni zintegrowany z infrastrukturą Zamawiającego na poziomie danych
w zakresie merytorycznym, architektury oraz technicznym. System będzie wymieniał informacje
z głównymi aplikacjami wykorzystywanymi w IMGW-PIB, tj.: SH, ST, LEADS, PERUN, COSMO,
ALADIN, AROME, i GFS poprzez CBDO i CBDH. Integracja systemu zostanie zrealizowana na
poziomie usług (web services) oraz dla „dużych plików” na poziomie plikowym z CBDO i CBDH.
System zostanie zainstalowany na serwerach wirtualnych dostarczonych przez Zamawiającego
wyposażonych w system operacyjny CentOS, pracujących w sieci wewnętrznej Instytutu.
Moduł integracyjny omówiony jest w załączniku nr 4 wraz załącznikami 4.1- 4.4.
System będzie wykorzystywał wyniki modeli numerycznych użytkowanych w IMGW-PIB. Na
potrzeby weryfikacji modeli system umożliwi edycję (w celu synoptycznej korekty) pól
wynikowych. Będzie również asymilował dane pomiarowo-obserwacyjne, które wspomagają
decyzję synoptyka w procesie korekty wyników modeli numerycznych. Na bazie tego wsadu system
będzie
dokonywał
dalszego
przetwarzania
danych,
aż
do
uzyskania
produktu
(pola
meteorologicznego) i jego prezentacji (wizualizacji lub publikacji w postaci plikowej). Istotną
funkcjonalnością systemu będzie edytowanie wyników modelu numerycznego w celu ich korekty.
Strona 4 z 33
Niezbędnym etapem analizy wyników numerycznych modeli prognoz pogody jest ocena
sprawdzalności modelu, krytyczna analiza wyników poprzednich cykli obliczeniowych. Ma to
ogromne znaczenie w procesie przypisywania wagi poszczególnym wynikom.
Z założenia System powinien być pomostem między wynikami modeli numerycznych stosowanych
w PSHM w pierwszej fazie procesu prognozowania, a prognozami wykonywanymi przez synoptyka.
Stanowić będzie platformę do weryfikacji wyników modeli numerycznych na podstawie danych
obserwacyjno-pomiarowych oraz wiedzy i doświadczeniu operacyjnego synoptyka i będzie służyć
w dalszym procesie monitorowania i nadzoru.
System tworzyć będą dwa fundamenty:
 prognozowanie – pre-analiza wyników modeli numerycznych,
 weryfikacja wyników modeli numerycznych,
Produkt finalny będzie miał możliwość dalszego, manualnego przetwarzania przez synoptyka,
możliwe będzie dodawanie komentarza, w postaci meta-danych. W przypadku braku komentarza,
synoptyk po uzyskaniu pewności, że wyniki są satysfakcjonująco wiarygodne będzie mógł zezwolić
na bezpośrednią publikację produktu.
II. ZAŁOŻENIA OGÓLNE
Zakłada się przede wszystkim stworzenie szkieletu aplikacji. Szkielet ten powinien zakładać
możliwość ciągłej rozbudowy o kolejne moduły, wynikające z doświadczeń i potrzeb pracy
operacyjnej. Ze względu na operacyjny charakter wykorzystania system powinien charakteryzować
się dużą szybkością pracy. Zamawiający ma na myśli takie działanie aplikacji, które zapewni pracę
bez przerw związanych z ładowaniem i przetwarzaniem danych. Przetwarzanie plików z danymi
musi odbywać się natychmiast po ich pojawieniu się w repozytorium plikowym. Ergonomia pracy
powinna być podobna do pracy ze stroną internetową. Czas pracy ma być komfortowy, serwer nie
powinien się blokować podczas przetwarzania algorytmów lub dłuższych zakresów czasowych, czas
odświeżania poniżej 3 sek.
System powinien składać się z wewnętrznej, relacyjnej bazy danych, webowego interfejsu
użytkownika i administratora systemu, systemu integracji i zasilania, dekodowania, eksportu danych
meteorologicznych, oraz dodatkowych modułów opisanych w pkt. III.
Strona 5 z 33
System zostanie osadzony w infrastrukturze zamawiającego. IMGW-PIB udostępni na potrzeby
realizacji projektu następującą infrastrukturę:
1. 1 maszynę wirtualną dla potrzeb przetwarzania danych GRIB (repozytoria plikowe, dane
źródłowe i przetworzone, aplikacje, usługi, logika) o następujących parametrach:
8 GB pamięci RAM
4 procesory wirtualne
Przestrzeń dyskowa 400 GB.
2. 1 maszynę wirtualną WWW (aplikacje, usługi, logika), do prezentacji danych wynikowych
4 GB pamięci RAM
2 procesory wirtualne
Przestrzeń dyskowa 40 GB.
3. Środowisko RDBMS Oracle w wersji 11.2.0.4 z przestrzenią dyskową 400 GB, baza umieszczona
jest na środowisku z pełną redundancją. Zamawiający wymaga, aby dostarczony system był
przygotowany do migracji do najnowszej wersji bazy danych PostgreSQL oraz był przygotowany do
pracy z bazą Oracle 12c. Wykonawca nie wykorzysta w żadnym momencie oraz pod żadnym
pozorem dodatkowych opcji bazodanowych Oracle dostępnych w silniku bazodanowym Oracle poza
posiadane przez Zamawiającego opcje bazodanowe. Istnieje możliwość i konieczność wykorzystania
opcji Oracle RAC (Oracle Real Application Clusters).
Zamawiający wymaga wykorzystania platformy opartej o UNIX lub Linux, preferowany system
operacyjny to CentOS. Wymaganie wynika z ograniczeń platformy systemu wirtualizacji.
Szczegółowy opis interfejsu WWW zawiera Załącznik nr 1.
III. MODUŁY DOSTARCZANEJ APLIKACJI:
1. Wewnętrzna relacyjna baza danych - Zamawiający dysponuje infrastrukturą oparta o bazę Oracle.
2. Moduł dekodujący dane wejściowe, umożliwiający:
a) Umieszczenie danych dostarczonych w postaci plików do bazy danych w postaci relacyjnej.
b) Działanie bezpośrednio po pojawieniu się danych.
Strona 6 z 33
c) Konfigurację typów plików w zależności od źródła i terminu. Zakres podstawowy danych
źródłowych omówiono w rozdziale IV, pkt. 1. Konfiguracja pozwalać będzie
administratorowi na modyfikację zakresu podstawowego.
d) Konfigurację filtrów danych importowanych do bazy danych w zależności od źródeł
(zakodowanych w plikach grib) i terminów ważności. Konfiguracja pozwoli na określenie
zakresu danych dekodowanych z grib dla importu do bazy danych.
3. Moduł eksportu danych umożliwiający:
a) Eksport danych znajdujących się w bazie danych w postaci relacyjnej do formatów plików
wymienionych w rozdziale IV, pkt. 2 dla wybranych punktów na mapie w określonym
czasie.
b) Ustalenie
nazw
plików
zawierających
meta
elementy
wg
następującej
maski:
PROD_ID_BT_xxZ_VT_xxxZ.ext, zawartych w katalogach, których struktura wskazywać
będzie na datę powstania (RRRR-MM-DD-GG_Z), gdzie:
i.PROD_ID – identyfikator produktu, wskazujący na nazwę pola danych,
ii.BT_xxZ – czas bazowy produktu, wyrażony w godzinach xx, czasu UTC (Z),
iii.VT_xxxZ – czas ważności produktu, wyrażony w godzinach xxx czasu UTC (Z),
iv.ext – rozszerzenie pliku wskazujące na jego typ (bmp, png, jpg, gif, svg, png, jpg, csv,
xml),
v. RRRR-MM-DD-GG_Z – rok-miesiąc-dzień-godzina powstania serii danych wyrażone
w czasie UTC (Z).
c) Ustalenie harmonogramów eksportów. Konfiguracja będzie pozwalała na określenie
harmonogramów dystrybucji plików wyjściowych przyporządkowanych do rodzaju
produktu, klasy produktu (model, obserwacja), źródła produktu, termin powstania.
Sterowanie tą konfiguracją będzie dostępne dla administratora systemu.
4. Moduł optymalizujący. Optymalizacja ma polegać na zarządzaniu archiwizacją i czyszczeniem
nieaktualnych danych. Dane przechowywane będą w bazie i/lub w repozytoriach do trzech dób,
przestarzałe dane moduł będzie usuwał. Moduł optymalizujący zachowa jednak funkcjonalność
trwałej archiwizacji danych, wyraźnie wskazanych przez użytkownika, wraz z określeniem czasu
utrzymywania archiwum (maksymalnie 5 lat).
5. Moduł integracyjny. Szczegółowe informacje w Załączniku 4.
Strona 7 z 33
IV. DANE WEJŚCIOWE I WYJŚCIOWE
1. Jako dane wejściowe do systemu wykorzystywane będą:
a) dane z sieci pomiarowo-obserwacyjnej: depesze SYNOP, METAR, TEMP,
b) dane z systemu telemetrii PSHM,
c) wyniki numerycznych modeli prognoz pogody:

COSMO (7 km i 2,8 km) (format danych grib)

ALADIN (format danych grib)

AROME (format danych grib)

GFS (0.25 deg) (format danych grib2)

modele nowcastingowe: INCA-PL, SCENE, SNOF (formaty danych csv, grib).
2. Formaty danych:
Wejście:
a) GRIB, opis: http://www.wmo.int/pages/prog/www/WMOCodes.html,
b) NetCDF, opis: http://www.unidata.ucar.edu/software/netcdf/,
c) BUFR, opis: http://www.wmo.int/pages/prog/www/WMOCodes.html,
d) pliki tekstowe w postaci csv, xml,
e) pliki graficzne (np.: bmp, png, jpg, gif, svg),
f) pliki z danymi georeferencyjnymi (shp, kml),
g) lub w innych formatach natywnych – w razie potrzeby opis zostanie dostarczony.
Wyjście:
Wszystkie dane wyjściowe z aplikacji wykonanych przez Wykonawcę będą generowane
w wybranych formatach z powyższej listy.
a) GRIB, NetCDF,
b) csv, xml,
c) png, jpg, gif, svg,
d) shp, kml.
3.
Wymaga się zastosowania otwartych i darmowych dekoderów plików grib/grib2:
1) Grib-api w wersji 1.13.0 lub wyższej (ECMWF), oparty na licencji Apache 2.0, źródło:
https://software.ecmwf.int/wiki/display/GRIB/License),
Strona 8 z 33
2) wgrib, wgrib2 (NCEP), oparte na licencjach otwartych lub zawartych w domenie publicznej,
źródła:
a) http://www.cpc.ncep.noaa.gov/products/wesley/wgrib.html,
b) ftp://ftp.cpc.ncep.noaa.gov/wd51we/wgrib/NOTICE,
c) http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/util/sorc/wgrib2.cd/grib2/wgrib2/LICENS
E-wgrib2
d) http://www.cpc.noaa.gov/products/wesley/wgrib2/).
3) innego dostarczonego przez Wykonawcę, opartego na darmowych, otwartych licencjach,
zawartych w domenie publicznej lub z licencją do użytkowania kompatybilną z dostarczanym
systemem.
Format NetCDF musi być obsługiwany przy użyciu darmowych, otwartych bibliotek.
System będzie umożliwiać rozbudowę, danych, poprzez integrację nowych bibliotek lub
modułów bez ingerencji w głównym kodzie programu.
V. WYMAGANIA W STOSUNKU DO WYKONAWCY:
1. Raportowanie postępu prac i uzgodnienia podczas spotkań w jednym ze wskazanych przez
Zamawiającego miejsc (Kraków, Warszawa, Wrocław) z częstością nie rzadziej, niż co
2 tygodnie. Zamawiający dopuszcza możliwość przeprowadzenia spotkania on-line przy pomocy
ogólnodostępnych narzędzi do konferencji internetowych. Ze strony Zamawiającego możliwe jest
zorganizowanie konferencji internetowej wykorzystującej infrastrukturę Microsoft LYNC,
Wykonawca może dostarczyć swoje rozwiązanie umożliwiające transmisję głosową oraz
wizualną przez współdzielony Pulpit. Każdorazowe zorganizowanie spotkania w formie on-line
musi być uzgodnione z przedstawicielem Zamawiającego.
2. Kody źródłowe będą tworzone wg. opisanych standardów kodowania, obejmujących minimum
formatowanie kodu, konwencje nazewnicze i konstrukcje programistyczne. Wykonawca
dostarczy dokument, z opisanymi zastosowanymi standardami.
3. Dostarczone oprogramowanie będzie zawierało udokumentowany kod źródłowy (standard
Doxygen 2.0), opatrzone czytelnymi komentarzami, niezależnie od elementów składowych
Strona 9 z 33
powinno być w pełni dostępne do edycji i przetworzenia przy użyciu darmowych kompilatorów
lub interpreterów.
VI.
SZCZEGÓŁOWY OPIS PODZADAŃ
Podzadania polegają na opracowaniu poszczególnych modułów do systemu. System powinien
zawierać moduły spełniające następujące funkcjonalności:
1. Moduł: Edytowanie pól wynikowych modeli numerycznych w celu ich korekty.
Narzędzie ma umożliwić następujące działania w celu korekty wyników modeli numerycznych
w trybie pracy operacyjnej na dyżurze synoptycznym:
Weryfikacja manualna i automatyczna po zadanych parametrach.
Weryfikacje wyników modeli numerycznych w oparciu o dane obserwacyjne.
Weryfikacja wyników modeli numerycznych w oparciu o pola statystyczne.
Weryfikacja wyników modeli w oparciu o różnice pomiędzy modelami z pre-analizy (warstwy
prezentacyjnej).
Szczegółowy opis w Załączniku nr 2.
2. Moduł: Przeliczanie pól modelowych z uwzględnieniem bieżących obserwacji naziemnych.
Narzędzie służyłoby do modyfikacji wartości prognostycznych wskaźników opartych na
wielowarstwowych poziomach atmosferycznych, na podstawie bieżących wskazań stacji
synoptycznych.
Ponowne przeliczenie wskaźników wielowarstwowych, w których dane naziemne z obserwacji
bieżącej, a górne z wyników z modelu dla wyższych warstw atmosfery – maksymalne
wykorzystanie danych pomiarowych – np. do przeliczania: CAPE, SRH, SHEAR.
Asymilacja danych pomiarowych – temperatura, wilgotność do modyfikacji diagramu
aerologicznego prognostycznego.
Weryfikacja danych operacyjnych - wymagana- możliwość wykorzystania danych punktowych
(dane z systemu telemetrii, dane SYNOP, prognoza numeryczna).
Szczegółowy opis w Załączniku nr 3.
VII. HARMONOGRAM PRAC
Termin realizacji: 30.09.2015
Wdrożenie systemu:
Strona 10 z 33
1. Opracowanie i przekazanie dokumentacji kodu wg standardu Doxygen 2.0 oraz dokumentacji
użytkownika, administratora oraz dokumentacji opisującej architekturę systemu.
2. Instalacja systemu na serwerach i udostępnienie na stanowiskach operacyjnych.
3. Warsztaty dla pracowników Zamawiającego.
Przyjmuje się następujące etapy realizacji zadania:
Etap
Opis
Termin realizacji
I. Opracowanie projektu 1. Analiza i projektowanie systemu – konsultacje 15.07.2015
Systemu
Wykonawcy z Zamawiającym w celu uzgodnienia
realizacji
poszczególnych
Konsultacje
prowadzone
elementów
w
sytemu.
ramach
spotkań
Wykonawcy z Zamawiającym, konsultacji on-line,
korespondencja e-mail.
i
2. Omówienie
developerskiego
dostosowanie
do
środowiska
udostępnionej
przez
Zmawiającego infrastruktury.
3. Określenie
i
zaprogramowanie
środowiska
testowego interfejsu do prezentacji. Testowe
sprawdzenie
dystrybucji.
Określenie
zakresu
funkcjonalności środowiska testowego odbędzie
się w formie wstępnych konsultacji, jednak
minimalny
zakres
to
przedstawienie
podstawowych funkcjonalności interfejsu www
prezentującego
następujące
parametry
meteorologiczne: temperatura powietrza, ciśnienie
atmosferyczne, prędkość i kierunek wiatru na
podstawie danych GRIB oraz danych z sieci
pomiarowo obserwacyjnej.
4. Wygenerowanie
dokumentacji
i
prezentacji
graficznej na podstawie uzgodnień dla każdego
z wymienionych powyżej zadań. Celem realizacji
Strona 11 z 33
niniejszego
punktu
Zamawiającego
z
Zamawiającego
dojdzie
do
Wykonawcą,
obecna
spotkania
po
stronie
będzie
osoba
odpowiedzialna za operacyjne zasilanie systemu
danymi. Podczas spotkania zostaną określone
zasady i harmonogramy dystrybucji.
5. Określenie harmonogramu i zakresu zadań dla
programisty.
II. Wykonanie, instalacja, 1. Programowanie części składowych systemu.
wdrożenie i
konfiguracja Systemu
2. Budowa/programowanie
wizualizacji
30.08.2015
produktów
wyspecyfikowanych
w
do
opisie
konfiguracji podstawowej, (załącznik 1, rozdział
III).
3. Implementacja funkcji interaktywnych interfejsu,
budowa narzędzi wizualizacji, personalizacji.
4. Wdrożenie systemu.
5. Konsultacje i raportowanie postępu prac zgodnie
z ustalonym harmonogramem spotkań.
III. Testy Systemu
1. Testowanie systemu, uzupełnienia i poprawki, 15.09.2015
opracowanie
i
sprawdzenie
dokumentacji,
szkoleń
pracowników 30.09.2015
finalizacja projektu.
IV. Przeprowadzenie
warsztatów dla
1. Przeprowadzenie
dla
Zamawiającego.
pracowników
Zamawiającego
Strona 12 z 33
4.
VIII. WARSZTATY DLA PRACOWNIKÓW ZAMAWIAJĄCEGO
Wykonawca przeprowadzi warsztaty dla pracowników Zamawiającego w Ośrodku Głównym i we
wszystkich lokalizacjach biur prognoz meteorologicznych Zamawiającego.
1. Rodzaje szkoleń
1) warsztaty administratorów i administratorów lokalnych
 forma – warsztaty on-line, warsztaty lokalne,
 lokalizacja - Ośrodek Główny IMGW-PIB lub miejsce działania poszczególnych zespołów
biur prognoz meteorologicznych,
 liczba uczestników – ok. 15 osób,
 ilość
warsztatów
–
jedne
przeprowadzone
1
raz
w
terminie
uzgodnionym
z przedstawicielem Zamawiającego,
 czas trwania - 8 godzin,
2) warsztaty dla użytkowników
 rodzaj warsztatów – lokalne,
 lokalizacja – miejsca działania poszczególnych zespołów biur prognoz meteorologicznych
(Gdynia, Szczecin, Białystok, Poznań, Warszawa, Wrocław, Kraków),
 liczba uczestników – łącznie około 80 osób, maksymalnie w jednych warsztatach 12 osób,
 ilość warsztatów – jedne w każdej lokalizacji 2 lub 3 razy, w terminach uzgodnionych
z przedstawicielem Zamawiającego,
 czas trwania - 8 godzin.
2.
Tematyka warsztatów
1) warsztaty dla synoptyków:
a) opis systemu, części składowe,
b) opis
interfejsu
użytkownika
przedstawienie
funkcji
operatora
(szczegółowo)
i administratora (pobieżnie) (m.in. początek pracy z systemem, przetwarzanie danych
w aplikacji, logowanie, uprawnienia, wymagania sprzętowe dla użytkownika),
c) prezentacja zastosowania aplikacji – demo wykorzystania funkcji w hipotetycznych
sytuacjach operacyjnych,
Strona 13 z 33
d) opracowanie ćwiczeń dla użytkowników do samodzielnego wykonania. Podstawowe
manipulacje w systemie (m.in. wyświetlenie danych do porównania, wybór modelu,
modyfikacja pola numerycznego, zapis, eksport),
e) dodatkowo szczegółowe zagadnienia w dwóch zakresach tematycznych:
Podstawowe zagadnienia programu warsztatów:

panel administratora

zarządzanie uprawnieniami użytkowników, przynależności do grup

ustawienia konfiguracyjne:

konfiguracja dekodowania

konfiguracja kalkulatorów

konfiguracja wartości domyślnych

konfiguracja palet.
2) warsztatów dla administratorów i IT:
a) dla administratorów w biurach prognoz i dla IT - warsztaty szczegółowe funkcji
administracyjnych, struktura przepływu danych, charakterystyka możliwych awarii i ich
usuwania, przedstawienie źródeł oprogramowania i interfejsu, podstawowe manipulacje
w kodzie oprogramowania służące do rozbudowy kolejnych modułów,
b) dodatkowo szczegółowe zagadnienia w dwóch zakresach tematycznych
 konfiguracja sprzętowa, konfiguracja aplikacji oraz aplikacji współpracujących,
 przedstawienie wykorzystywanych technologii (np. jquery, php, Oracle),
 wymagania systemowe, efektywność działania,
 sposoby optymalizacji sprzętowej i softwarowej,
 możliwości monitoringu poprawności działania, alertowanie o braku danych, błędach,
 zarządzanie modułami aplikacji,
 zakres konfiguracji aplikacji,
 monitorowanie,
 zarządzanie użytkownikami,
 kopie bezpieczeństwa,
 wymagania wydajnościowe i dostępność.
Strona 14 z 33
3) Program warsztatów zostanie wcześniej skonsultowany z przedstawicielami IMGW-PIB.
4) W ramach warsztatów ma być dostarczona kompletna instrukcja obsługi dla poszczególnych
grup pracowników – administratorów, administratorów lokalnych systemu, użytkowników
systemu.
IX.
ZAKRES WSPARCIA TECHNICZNEGO
Zakres wsparcia technicznego rozumiany jest jako realizacja warunków gwarancji.
1. Minimalny wymagany okres świadczenia serwisu i wsparcia powykonawczego systemu wynosi
12 miesięcy. Bieg terminu gwarancji rozpoczyna się od dnia podpisania Protokołu Odbioru
Końcowego.
2. Gwarancja na przedmiot Umowy, świadczona będzie w siedzibie Zamawiającego.
3. Wykonawca zobowiązuje się do przyjmowania zgłoszeń w formie telefonicznej oraz poczty
elektronicznej o awarii przez 7 dni w tygodniu, 24 godziny na dobę.
4. Wykonawca zobowiązuje się usunąć awarię w następującym czasie od momentu zgłoszenia
przez Zamawiającego:
a) dla błędu – 18 godzin,
b) dla usterki – 24 godziny.
5. Priorytet awarii ustala Zamawiający w swoim zgłoszeniu, zgodnie z poniższymi definicjami:
a) błąd - niedziałanie lub niepoprawne działanie Systemu lub działania niezgodne
z dokumentacją użytkownika lub administratora lub z projektem aplikacji, uniemożliwiające
jego używanie w obszarze zastosowań,
b) usterka - niepoprawne działanie Systemu umożliwiające wykonywanie jego funkcji, ale
w sposób utrudniony lub inny niż wynika z dokumentacji użytkownika lub administratora lub
wymagające wykonania dodatkowych czynności poza zalecanymi w dokumentacji.
6. Gwarancja nie obejmuje usuwania problemów w prawidłowym funkcjonowaniu Systemu
wynikających z przyczyn technicznych niezależnych od Wykonawcy, np. problemów
wniesionych przez inne elementy współpracujące z Systemem i niebędące przedmiotem Umowy
(błędy użytkowników, wirusy komputerowe, itp.).
7. Nośniki oprogramowania Systemu, płyta CD oraz nośniki typu Pendrive objęte są 90-dniową
gwarancją.
Strona 15 z 33
X. WYMAGANIA OGÓLNE
1. Wykonawca oświadcza, że przysługują mu wyłączne i nieograniczone prawami innych osób,
majątkowe prawa autorskie do utworów powstałych w związku z realizacją Umowy.
2. Wykonawca oświadcza, że do Systemu powstałego w związku z realizacją Umowy, przysługują
mu wyłączne i nieograniczone prawami innych osób, majątkowe prawa autorskie.
3. Z chwilą przekazania przedmiotu Umowy Zamawiającemu, Wykonawca przenosi na
Zamawiającego całość autorskich praw majątkowych do utworów, o których mowa w ust. 1
oraz Systemu wraz z kodami źródłowymi, na wszystkich polach eksploatacji, określonych w art.
74 ust. 4 Ustawy z dnia 4 lutego 1994 roku o prawie autorskim i prawach pokrewnych (Dz. U.
2006 Nr 90 poz. 631 z późniejszymi zmianami) w brzmieniu obowiązującym w dniu zawarcia
Umowy, w tym w szczególności:
a) używania i wykorzystania rozbudowanego Systemu w całości,
b) utrwalania i zwielokrotniania wszelkimi technikami w całości lub w części,
c) zwielokrotniania poprzez dokonywanie zapisu na nośnikach elektronicznych, dyskietkach,
płytach kompaktowych oraz nośnikach magnetycznych,
d) publicznego wystawiania i wyświetlania,
e) wprowadzania do pamięci komputera i umieszczania w sieci Internet,
f) publicznego rozpowszechniania w sposób inny aniżeli wskazany w pkt 4,
g) aktualizowania danych w Systemie.
4. Z chwilą odbioru przedmiotu Umowy lub jej części następuje również nabycie przez
Zamawiającego własności wydanych mu egzemplarzy dokumentacji.
5. Wykonawca, przenosząc majątkowe prawa autorskie na Zamawiającego, zgodnie z ust. 3
jednocześnie oświadcza, że:
a) nie narusza autorskich praw majątkowych osób trzecich, jednakże Wykonawca zobowiązuje
się do przejęcia wszelkich ewentualnych roszczeń osób trzecich w przypadku naruszenia
autorskich praw majątkowych tych osób,
b) nie udzielił przed przeniesieniem majątkowych praw autorskich żadnych licencji na
wykorzystywanie rozbudowanego Systemu,
Strona 16 z 33
c) autorzy powstrzymają się od wykonywania swoich praw osobistych w stosunku do
rozbudowanego Systemu, będącego przedmiotem Umowy.
Załącznik 1
INTERFEJS
Aplikacja będzie działać w oparciu o profile użytkowników, logowanie i uprawnienia
synchronizowane z Active Directory, które jest wdrożone i stosowane w IMGW-PIB. W ramach
jednego użytkownika zapewniona będzie możliwość wyboru predefiniowanego profilu (np. zakres
nowcastingu, zakres prognozy na 5 dni, region Polski, cała Polska). Wielkość i zestaw profili
dostępnych dla użytkownika będzie możliwa do konfiguracji z poziomu administratora systemu.
Interfejs powinien być oparty na otwartych technologiach web ([php, rubby, python], js, jquery,
html3).
I. Tryby pracy systemu
Aplikacja będzie zawierać następujące tryby pracy:
1.
Tryb administratora.
2.
Tryb użytkownika.
3.
Moduł integracyjny.
Tryb administratora
W module administratora użytkownik będzie miał dostęp do zmian globalnych ustawień systemu
takich jak:
1. strona z monitoringiem pracy systemu,
2. strona do zarządzania użytkownikami, przypisywania im ról,
3. strona z ustawieniami globalnymi użytkowników,
4. strona umożliwiająca zmiany globalnych ustawień systemu (baza danych, dekodowanie, dane
wyjściowe),
5. strona umożliwiająca tworzenie nowych produktów, ich kategoryzowanie, umieszczanie
w poszczególnych lokalizacjach.
Strona 17 z 33
Tryb użytkownika
W module użytkownika system składał będzie się z następujących podstron:
1. ustawienia,
2. strona startowa,
3. strona użytkownika,
4. strona monitoringu systemu (braki danych, opóźnienia),
5. strona z danymi zlokalizowanymi geograficznie (mapy),
6. strona z prezentacją danych w postaci tabelarycznej,
7. strona z prezentacjami w postaci wykresów,
8. strona Mix (umożliwiająca dowolne łączenie funkcjonalności z pkt. 2.5-2.7).
Uwagi i komentarze do funkcjonalności Trybu Użytkownika
Aplikacja ma umożliwiać zmiany pracy pomiędzy poszczególnymi stronami w sposób maksymalnie
zachowujący parametry pracy.
W każdym stanie powinna istnieć możliwość zapisu aktualnych ustawień aplikacji (położenia okien,
wybranych parametrów) i możliwość umieszczenia ich jako skrótu na stronie głównej.
W przypadku strony Mix aplikacja ma zapewniać możliwość synchronizacji wyświetlanych
parametrów pomiędzy elementami strony.
Domyślnie synchronizacja powinna dotyczyć dla czasu wyświetlania, dla pozostałych parametrów
możliwość konfiguracji i zmiany domyślnych ustawień na poziomie administratora bądź
użytkownika.
Dla
każdego
zobrazowania
musi
być
zachowana
możliwość
uruchomienia
animacji
(z konfigurowalną przerwą), jak i automatycznego odświeżania (w przypadku pojawienia się danych
z nowszego zestawu).
Uwagi do podpunktu 5 w Trybie Użytkownika - strona z danymi zlokalizowanymi geograficznie
(mapy).
1. Możliwość prezentacji kilku (1-12) obrazów na jednej stronie wzajemnie zsynchronizowanych
czasowo.
2. Dla poszczególnych obrazów możliwość wyboru dowolnego typu danych meteorologicznych,
sposobu zobrazowania (izolinia, pole barwne, wartości) oraz podkładów. Jako warstwa może być
Strona 18 z 33
też użyty obraz w formacie png, gif, jpg, svg pochodzący z zewnętrznych źródeł (np. system
Leads, Dart) zorientowanych geograficznie przy pomocy panelu administratora.
3. Nakładanie warstw na pojedynczej mapie - funkcjonalność nakładania wielu danych
geograficznych na jednym obrazie:
a) możliwość włączania, wyłączania warstw oraz ich wzajemnego położenia (funkcjonalność
zbliżona do pracy na warstwach w Photoshop) oraz zmiany stopnia ich przeźroczystości,
b) domyślnie wszystkie warstwy zsynchronizowane w czasie - możliwość desynchronizacji wtedy niezbędne wyświetlenie wyraźniej informacji o braku synchronizacji czasowej,
c) możliwość zsynchronizowania wybranych warstw pod względem parametrów lub poziomów,
d) dla każdej warstwy (pomijając warstwy będące zaimportowanymi obrazami z zewnętrznych
źródeł, np. radarowy, system detekcji wyładowań) dane muszą być możliwe do wyświetlania
za pomocą izolinii, wartości w siatce, wartości w pre-definiowanych punktach (np. zgodnych z
listą stacji SYNOP), pola barwnego. Kolory izolinii oraz skok (niekoniecznie liniowy)
powinien być możliwy do zdefiniowania za pomocą panelu administracyjnego, analogicznie
dla pola barwnego. Możliwość wybrania, zmiany palety barwnej w czasie prezentacji.
Możliwość wykorzystywania dynamicznej palety barwnej (w zależności od zakresu
prezentowanych danych), jak i statycznej dla stałego zakresu danych,
e) linia czasowa w postaci suwaka - z możliwością definiowania skoku oraz dodatkowy suwak do
przemieszczania się po czasie bazowym modelu,
f) funkcjonalności z punktów a-e muszą mieć możliwość zdefiniowania jako skróty klawiszowe,
g) w zależności od wybranej opcji najechanie myszą na polu z danymi ma wyświetlać:
 wartości pól w danej lokalizacji mapy zgodnych z wyświetlanymi parametrami,
 wszystkie operacje mają w maksymalny sposób zachowywać parametry z wyświetlanej
mapy (wybrany NWP, zestaw parametrów, czas bazowy NWP, czas prognozy),
 kliknięcie w danej lokalizacji mapy pozwala na:
 wyświetlenie
meteogramu
(pola
w
meteogramie
definiowalne
na
poziomie
administratora),
 wyświetlenie przekroju pionowego (pola w przekroju definiowalne na poziomie
administratora - po wyświetleniu możliwość dodania dowolnie wybranego pola lub
zmiana parametrów wyświetlania),
Strona 19 z 33
 możliwość wykonania przekroju pionowego dla wybranej linii łamanej (trasy) za pomocą
podwójnego kliknięcia (np. ctrl + klik),
 wyświetlenie modyfikowalnego sondażu pionowego - opis w modułach,
h)
wszystkie operacje mają w maksymalny sposób zachowywać parametry z wyświetlanej
mapy (wybrany NWP, zestaw parametrów, czas bazowy NWP, czas prognozy),
i) prezentacja powinna udostępniać możliwość automatycznego odświeżania,
j) dla wszystkich danych, które posiadają odniesienie przestrzenne niezbędny jest zapis
wybranych i pre-konfigurowanych danych analizowanych i danych wynikowych (np. izolinie)
w formie pliku geobazy z konfigurowalną nazwą pliku z elementami dynamicznymi
definiującymi warstwę.
Uwagi do podpunktu 6 w Trybie Użytkownika – strona z prezentacją danych w postaci tabelarycznej
1. W prezentacji tabelarycznej mogą znaleźć się:
a) dowolne pola meteorologiczne zawarte w danych wejściowych,
b) dane przeliczone wewnątrz systemu na podstawie algorytmów zadanych przez administratora,
c) dane interpolowane dla wybranych lokalizacji lub obszarów.
2. Dostępne obszary oraz lokalizacje definiowalne na poziomie panelu ustawień użytkownika.
3.
W tabeli możliwość sortownia i filtrowania w kolumnach.
4.
Możliwość
konfiguracji
wyświetlanych
elementów
z
poziomu
panelu
konfiguracji
użytkownika.
5.
Możliwość eksportu danych z tabeli do pliku csv.
6.
Możliwość eksportu danych posiadających odniesienie przestrzenne do pliku geobazy.
7.
Prezentacja powinna udostępniać możliwość automatycznego odświeżania.
Uwagi do podpunktu 7 w Trybie Użytkownika – strona z prezentacjami w postaci wykresów.
1. Prezentacja w postaci wykresu powinna zapewniać następujące minimalne funkcjonalności:
a) meteogram z konfigurowalnymi polami,
b)interaktywny przekrój pionowy,
c) sondaż pionowy,
d)histogram dla wybranego parametru,
Strona 20 z 33
e) wykres 2D dowolnych zmiennych z możliwością dodawania i usuwania wyświetlanych danych
w czasie prezentacji.
2. Wszystkie ww. sposoby prezentacji powinny zapewniać podstawową interaktywność:
a) dodawanie i usuwanie wyświetlanych parametrów,
b) zmiany parametrów wyświetlania (np. wybrany NWP, zestaw parametrów, czas bazowy
NWP, czas prognozy),
c) skalowanie.
3. Możliwość eksportu otrzymanego obrazu (png, jpg, svg).
4. Prezentacja powinna udostępniać możliwość automatycznego odświeżania.
II.
Cechy systemu
1. System powinien zapisywać historię sesji - możliwość cofnięcia się do danych wyświetlanych
w poprzednich krokach.
2. System powinien umożliwiać przesłanie pełnej informacji o wyświetlanych danych np. za
pomocą adresu url (możliwość przesłania użytkownikowi w innej lokalizacji tej samej formy
wizualizacji).
3. Interfejs powinien działać płynnie na stacjach roboczych (komputery klasy PC Pentium 4, 2 GB
RAM) w przeglądarkach Firefox 32.0 +, Internet Explorer 10.0+, Chrome 40.0+.
4. Możliwość równoczesnego przeglądania danych przez najmniej 40 użytkowników na raz.
5. Możliwość prezentowania danych w różnych odwzorowaniach kartograficznych (definiowalnych
na poziomie administratora), minimum następujące:
a) Merkator
b)Lambert
c) natywne dla danego pola NWP
d)układ PUWG 92, domena 800x900 km, xll 50000, yll 30000
e) zunifikowane podkłady stosowane w IMGW-PIB.
6. Możliwość skalowania, przesuwania map (może być oparte o gmaps bądź OpenLayers),
możliwość zmiany podkładów geograficznych jak również ich definiowania (np. dodatkowe
punkty, wybrane granice).
7. System powinien zapewniać możliwość umieszczania na mapie wybranych symboli, linii,
Strona 21 z 33
obszarów (na dodatkowej warstwie) oraz mieć możliwość ich udostępnienia innym
użytkownikom lub wykorzystania na innych podkładach - dane te przy przenoszeniu muszą być
zorientowane geograficznie, a nie względem obrazu. System zapewni możliwość ich eksportu
przynajmniej w formacie png oraz w formatach wektorowym (kml, svg) oraz w formie geobazy.
1. Dla wybranego pola numerycznego system powinien pozwalać na jego ręczną edycje - patrz punkt
VI-2.
2. W przypadku prezentacji punktowych danych wynikowych – na polu siatkowym możliwa
wizualizacja poszczególnych elementów meteorologicznych w postaci palety barwnej,
naniesionego pola punktowego dla wskazanych lokalizacji oraz/lub wartości ekstremalnych dla
zadanego obszaru np. województwo, powiat, konglomerat województw.
3. Przy prezentacji danych punktowych, w przypadku skalowania możliwość grupowania bądź
dyskryminacji zgodnie z zadanym przez administratora dla danego typu danych algorytmem (np.
min, max, średnia, mediana).
4. System ma zapewniać możliwość porównania wyników z różnych modeli NWP z danymi
obserwacyjnymi (telemetria, synop,) oraz z wcześniejszymi przebiegami modeli.
III Katalog produktów dostępnych w konfiguracji podstawowej
1. Parametry z obserwacji (SYNOP, Telemetria):
- temperatura 2m,
- temperatura punktu rosy 2m,
- wiatr na poziomie 10 m (kierunek i prędkość),
- wiatr maksymalny (z telemetrii).
- porywy wiatru (z SYNOP).
- ciśnienie – MSLP,
- opad (wysokość) w interwałach: 10 min, 30 min, 1h, 3h, 6 h, 12 h.
2. Lista parametrów do publikacji w konfiguracji podstawowej, dostępnych w plikach grib.
- wskaźniki konwekcyjne:
 SBCAPE (Surface Based Convective Available Potential Energy),
 MUCAPE (Most unstable CAPE),
 CIN (Convecive Inhibition),
Strona 22 z 33
 MLCAPE 1km (Mixed Layer 0-1 km CAPE),
 MLCIN 1 km (Mixed Layer 0-1 km CIN),
 EHI,
 LI (Lifted Index),
 KI (K Index)
- opad (Precipitation) w interwałach: 3h, 6 h, 12 h
- typ opadu (Precipitation/type) w interwałach: 3h, 6h, 12 h
- TPW (Total Precipitable Water),
- ciśnienie - MSLP,
- wiatr na poziomie 10 m (kierunek i prędkość),
- temperatura na poziomie 2m,
- temperatura punktu rosy na poziomie 2m,
- SHR (Shear): 0-1km, 0-3km, 0-6km
- SRH: 0-1km, 0-2km, 0-3km
- ponadto parametry na wybranych poziomach izobarycznych:
dla każdego z poziomów izobarycznych: 300 mb, 500 mb, 700 mb, 850 mb, 925 mb, 1000 mb
następujące produkty:
 wiatr (wind),
 temperatura (Temperature),
 temperatura ekwiwalentno potencjalna (Theta-E),
 wilgotność względna (Relative humidity),
 prędkość pionowa (Vertical Velocity),
 dywergencja/konwegencja (Divergence),
 wirowość względna (Relative vorticity)
Strona 23 z 33
Załącznik nr 2
Moduł modyfikacji pola modelowego
1. Moduł ma pozwalać na modyfikację pola gribowego przez synoptyka. Jako pole bazowe może
służyć zarówno czyste dane z modelu NWP, kombinacja danych z kilku modeli, oraz dane
z modeli NWP + algorytmy statystyczne bazujące na dodatkowych parametrach (np. wysokość w
m n.p.m, rodzaj powierzchni, pora roku i inne). Algorytmy definiowalne zarówno na poziomie
administratora jak i użytkownika.
2. Minimalnie moduł ma zapewniać możliwość korekty poprzez następujące metody:
a) dla prezentowanego pola możliwość zaznaczenia obszaru poddawanego korekcie i dla
wybranego obszaru możliwość zmiany wartości pola w sposób absolutny, addytywny,
multiplikatywny
lub
inny
zgodny
ze
skonfigurowanym
algorytmem,
opcjonalnie
z możliwością zdefiniowania rozkładu przestrzennego zmiany (np. rozkład gaussa, stała
wartość) oraz wpływu na otocznie zaznaczonego obszaru (zasięg + kształt wpływu),
możliwość dokonania równocześnie korekty na dany moment czasu prognozy jak również
możliwość zdefiniowania wpływu na okresy w pobliżu.
Przykładowo - zmiana temperatury o +5°C na godz. 12 UTC może powodować:

brak jakichkolwiek zmian w prognozie na pozostałe kroki czasowe

dla terminów +/- 6h może powodować zmianę o +5°C

dla terminów w zakresie +/- 3h może powodować zmianę zgodną z wybranym rozkładem
(np. +5*(3-∆ t)/3).
Dla wybranego obszaru zainteresowania w dodatkowym oknie (panelu) powinien wyświetlać się
histogram z wartościami przed i po korekcie.
b) możliwość wybrania wartości zgodnych z zadanym filtrem (np. T max > 32 st. C) i dokonanie
operacji tylko na tak wybranych danych. Analogicznie jak dla sposobu 1. możliwość
definiowania wpływu zarówno na sąsiednie terminy, jak i dla sąsiednich obszarów,
c) możliwość łącznia obu ww. sposobów selekcji,
d) możliwość wybrania elementów charakterystycznych pola na mapie (max, min, izolinia)
i zmiany ich położenia. Analogicznie do punktów 1. i 2. system powinien pozwalać na
propagację zmian w czasie zgodnie z wybranym algorytmem,
e) możliwość wybrania punktów elementów charakterystycznych, zarówno z wcześniej
Strona 24 z 33
zdefiniowanej listy, jak i interaktywnie, dokonanie dla nich korekty pola meteorologicznego
i na podstawie zadanego algorytmu wyliczenie korekty dla całego obszaru,
f) możliwość
importowania
już
wypełnionej
listy ze
zmodyfikowanymi
wartościami
z zewnętrznej aplikacji (np. w postaci pliku csv, xml) i na jej podstawie wprowadzenia korekty
dla całego obszaru.
W trakcie wprowadzania zmian system powinien pozwalać na sprawne i szybkie przełączanie
pomiędzy różnymi polami - zarówno tymi w trybie edycji (korekty), jak i w trybie podglądu.
3. Administracja modułu:
a) system powinien zapewniać z poziomu administratora przypisanie maskowania obszarów do
modyfikacji w zależności od obszaru osłony danego biura (użytkownika, przypisania
użytkownika do jednostki organizacyjnej),
b) możliwe funkcje rozkładu korekty powinny być definiowalne z poziomu panelu
administratora, analogicznie zakresy propagacji czasowej i przestrzennej,
c) w celu stworzenia możliwych algorytmów (funkcji rozkładu) korekty, administrator powinien
mieć
możliwość
arytmetyczne,
wykorzystania
logiczne,
inne),
podstawowych
wykorzystania
operatorów
dowolnie
matematycznych
zdefiniowanych
(np.
stałych,
wykorzystania danych związanych z lokalizacją, datą i czasem, wartościami różnych (nie tylko
aktualnie modyfikowanego) pól meteorologicznych (bądź danych statystycznych) dostępnych
w systemie,
d) w zależności od wybranego pola (jego charakterystyki fizycznej) zapewniona możliwość
przypisania domyślnego sposobu propagacji korekty, jak również możliwość zablokowania
niektórych sposobów korekty dla danego pola,
e) administrator powinien mieć możliwość definiowania więzów pomiędzy danymi (korektami),
np. zmiana temperatury maksymalnej w ciągu dnia powinna pociągać za sobą zmianę
przebiegu temperatury w ciągu dnia,
f) administrator powinien mieć możliwość definiowania automatycznych ostrzeżeń dla synoptyka
zgodnych z zadanymi algorytmami (np. temperatura maksymalna z dnia nie może być
mniejsza niż temperatura minimalna z nocy, przy dodatniej temperaturze nie może padać śnieg
itp.).
Strona 25 z 33
4. Administracja na poziomie użytkownika:
a) system powinien zapewnić dla dowolnego synoptyka możliwość konfiguracji domyślnych
ustawień korekty (w ramach zakresów dopuszczonych przez administratora),
b) system powinien zapewnić możliwość zapisania preferowanego wyglądu danych do edycji.
5. Jako element wyjściowy modułu korekty możliwe będą następujące produkty:
a) dane w formacie grib ze zmodyfikowanymi wartościami przez synoptyka,
b) dane w formacie grib z wartościami zmian wprowadzonymi przez synoptyka,
c) dane w formacie xml, csv zawierające wartości danych w wybranych punktach,
d) obrazy (png, jpg, svg) z wizualizacją zmienności parametrów w czasie w wybranych punktach
(meteogramy), pola i wygląd definiowalne z poziomu użytkownika,
e) obrazy (png, jpg, svg) z wizualizacją przestrzenna parametrów - definiowalne z poziomu
użytkownika.
Przykładowa Procedura zastosowania modułu modyfikacji pól modelowych w oparciu
o prognozę synoptyczną
Aplikacja do edycji i weryfikacji prognozy numerycznej wynika z zapotrzebowania na interfejs
umożliwiający ręczną manipulację danymi modelowymi. Poniżej przykład zastosowania. Zasada
działanie modułu opisana na przykładzie założeń do aplikacji generującej prognozy średniego opadu
na zlewnię.
Przykład zastosowania:
Podział zlewni w zależności od rejonu osłony jest mocno urozmaicony, dlatego program powinien
pozwalać na sprawne zarządzanie danymi tak, by synoptyk mógł dokonać weryfikacji w sposób
możliwie prosty i szybki, a jednocześnie, aby cała procedura pozwalała na wzrost jakości samej
prognozy.
Dane wejściowe/wyjściowe
Na wejściu system otrzymywać będzie prognozę średniego opadu na zlewnię, aktualnie są to Aladin,
Cosmo i modele nowcastingowe (obecnie są to Inka-PL, SCENE), ale z możliwością pobrania
również GFS. Dodatkowo mogą być różne warianty tych modeli (Cosmo 2,8 km, Arome). Będą to
prognozy z różną rozdzielczością czasową (np. Aladin przez pierwsze 30 h dysponuje
rozdzielczością 1h, potem 3 h). Wyniki modeli są dostarczane w trybie normalnym 2x na dobę,
Strona 26 z 33
w sytuacji kryzysowej 4x na dobę, co 6 h.
Na wyjściu - na wyjściu zweryfikowana prognoza z rozdzielczością 1 h. Horyzont czasowy
prognozy, jaki nas interesuje to 3 doby (w Aladin oczywiście póki co mniej). Dla okresów, gdy
model podaje prognozy z rozdzielczością 3 h wartości 1h są interpolowane (średnia).
System będzie miał możliwość przechowywania danych archiwalnych, operacyjnie do 3 dni do
badania historii prognoz, nieoperacyjnie – pełne archiwum.
Baza danych
Niewątpliwie system będzie musiał komunikować się z zewnętrzną bazą danych, preferowana np.
Exadata – zarządzana w WO MOK lub C2.6. Prawdopodobnie niezbędna będzie osobna,
wewnętrzna baza danych.
Interfejs
Preferowanym interfejsem użytkownika jest strona Web.
Projekt layoutu wygląda w uproszczeniu następująco:
Rysunek 1. Uproszczony schemat rozmieszczenia elementów w aplikacji.
Strona 27 z 33
Użytkowanie
Obsługa systemu odbywałaby się w poszczególnych etapach:
1. Wybór modelu.
2. Wybór czasu. Na górze strony jest strzałka czasu. Dostępne są na niej najbliższe 3 doby.
Odpowiedni suwak pozwala na zaznaczenie odpowiedniego przedziału czasowego, dla którego
dokonywane będą operacje. Dla tego przedziału czasowego prezentowany jest wykres
słupkowy do korekty w prawym oknie.
3. Wybór interwału czasowego do korekty prognozy – na górze strony pasek wyboru interwału
1h, 3h, 6h, 12h.
4. Wybór obszaru (lewe okno). Na mapie Polski/obszaru osłony meteorologicznej/województwa
(możliwy wybór skali). Na mapie naniesione są kontury: województw, subregionów, zlewni.
5. Zaznaczanie. Kliknięcie myszy z wciśniętym klawiszem Ctrl pozwala zaznaczyć wszystkie
zlewnie objęte przez dany subregion, kliknięcie na zlewnie bez Ctrl pozwala klikać/odklikać
poszczególne zlewnie.
Podkład wewnątrz zlewni jest pokolorowany w zależności od wysokości prognozowanego
opadu średniego – wynik z modelu numerycznego przed edycją. Stała skala barw w zależności
od wartości średniego opadu na zlewnię.
6. Zasada grupowania do edycji jest taka, że synoptyk wybiera grupę zlewni, które
charakteryzować się będą podobnym opadem. Może to być subregion lub wybrane zlewnie.
7. Wykres obok mapy (prawe okno) w zadanym przedziale czasu i z rozdzielczością czasową
określoną z góry (3, 6, 12 h) prezentuje histogramy opadu średniego dla zaznaczonej zlewni
lub w przypadku zbioru zlewni – średni opad dla tego zbioru (należy go przeliczyć
proporcjonalnie do powierzchni zaznaczonych zlewni). Wewnątrz poszczególnych słupków
histogramu widoczne są wartości godzinowe średniego opadu na zlewnię.
Adjustacja
1. Synoptyk dla okresów interwałów 12h, 6h, 3h może określić opad całkowity z góry. Wtedy
niezależnie od tego, jaki opad wynikał z prognozy modelowej, opad w interwale zostanie
znormalizowany do wartości podanej przez synoptyka.
Np. mamy rozkład natężenia opadu dla grupy kilku zlewni, w którym w ciągu 12 h spadnie
Strona 28 z 33
15 mm, przy czym w pierwszych 6 h spadnie 10 mm, w drugich 6h 5 mm. Synoptyk podnosi
wartość opadu za 12 h do 30 mm. Rozkład natężenia zostanie podniesiony proporcjonalnie – w
pierwszych 6 h do 20 mm, w drugich do 10 mm. Dalej rozkłada opad po równo dla danego
interwału czasowego (tu 6 h) do skali najmniejszej (1h), zachowując godzinową strukturę
z modelu. W ten sposób dochodzimy do danych wyjściowych dla hydrologów – średni opad na
zlewnię krokiem 1 h.
2. Takie działanie można przeprowadzić także dla obszaru subregionu. Zostaną zdefiniowane
zlewnie przynależne do poszczególnych subregionów. Możliwość dodawania/odejmowania
zlewni od subregionu.
3. Możliwa jest opcja, że synoptyk akceptuje prognozę wysokości opadu z modelu dla dłuższego
interwału czasowego, ale koryguje rozkład czasowy, czyli zmienia sumy opadów dla
mniejszych interwałów przy założeniu, że suma całkowita nie ulegnie zmianie. Czyli
możliwość deklarowania, czy suma jest stała, czy modyfikowana.
4. Konieczna opcja akceptacji dla danego obszaru prognozy modelowej – albo domyślne
zostawienie danych modelowych, jeśli nie było korekty.
5. W momencie, gdy korygujemy średni opad na zbiór zlewni dokonuje się pewne uśrednianie
tego parametru dla poszczególnych zlewni, dlatego zaznaczamy tylko te zlewnie, w których
zakładamy w miarę jednorodne wartości średniego opadu.
Plik wynikowy
Jako wynik modyfikacji otrzymujemy pole opadu średniego na zlewnie, w którym doszło do ręcznej
modyfikacji wartości. Niezależnie czy synoptyk poprawiał słupki o szerokości (interwale) 12 h, 6 h,
3 h czy 1h, wynik korekty wpływa na sumy opadu w każdym zakresie czasowym. . Sposób i format
przekazania danych do bazy hydrologicznej (SH) do ustalenia.
Funkcjonalności dodatkowe
1. Historia prognoz.
2. Moduł weryfikacyjny – prezentacja zgodności prognozy z danymi otrzymanymi od
hydrologów (wyliczony na podstawie danych pomiarowych średni opad na zlewnię), z sieci
pomiarowej.
3. Możliwość prezentacji opadu minimalnego i ekstremalnego dla korygowanego obszaru/zlewni.
Strona 29 z 33
Załącznik nr 3
MODUŁ: PRZELICZANIE PÓL MODELOWYCH
Podstawą zastosowania modułu polega na tym, że błędy parametrów przypowierzchniowych są
najtrudniejsze do prognozowania przez modele numeryczne. Wyższe poziomy izobaryczne
prognozowane są z większą dokładnością, ponieważ na tych poziomach występuje znacznie
mniejsze urozmaicenie i wartości parametrów są w znaczącym stopniu wygładzone przestrzennie.
Źródła danych:
1. Obserwacje naziemne: SYNOP, dane z systemu telemetrii.
2. NWP – pola modeli numerycznych:
 ALADIN
 AROME
 COSMO
 GFS
 Modele nowcastingowe: INCA-PL, SCENE, SNOF.
Produkt przetworzony, pochodzący z modułu edycji pól wynikowych modeli numerycznych.
Wszystkie powyższe zwane będą dalej NWP lub „modele numeryczne”.
Tryby pracy (możliwe zastosowanie modułów 1 i 2):
1. Tryb prezentacji. W tym trybie wyświetlane byłyby pola obserwacji.
2. Tryb edycji.
Procedura zastosowania modułu w oparciu o dane pomiarowe:
1. Wybór modelu referencyjnego. Możliwe zastosowanie modelu wynikowego, pochodzącego
z modułu edycji pól wynikowych modeli numerycznych (Zał. 2). Pierwsza weryfikacja powinna
polegać zestawieniu wyników z wybranych modeli (możliwość przełączania źródła danych
modelowych) dla danego terminu z odpowiednim polem obserwacji. Dostępne terminy do
porównania to: ostatnia pełna godzina oraz pełne godziny wstecz, aż do terminu początku biegu
modelu.
2. Zestawienie wyników NWP i obserwacji naziemnych odbywać się powinno poprzez nakładanie
wartości obserwacyjnych (np. temperatura powietrza, wilgotność powietrza, kierunek i prędkość
wiatru) na tło modelowe. W prezentacji wyświetlane będą parametry na poziomie gruntu (SFC).
Strona 30 z 33
Prezentacja zestawienia będzie następująca – pole NWP obszary i/lub kontury, pole obserwacji
naziemnych – w postaci nakładania punktowego (cyfry, barwne punkty, krążki synoptyczne).
2. Podczas porównania NWP z obserwacjami naziemnymi zachodzi subiektywna ocena synoptyka
skutkująca wyborem najlepiej pokrywających się wartości NWP z wynikającymi z obserwacji.
W ten sposób określany jest model referencyjny – dostępny do dalszej obróbki.
3. Po wyborze modelu referencyjnego, dla danej godziny, system pozwala na podmianę
przypowierzchniowego pola NWP interpolowanymi wartościami z obserwacji naziemnych.
Domyślnie podmiana polegać powinna na kompletnym wypełnieniem wartości parametrów
przypowierzchniowych wartościami interpolowanych obserwacji naziemnych. Poza granicami
Polski, gdzie dostęp do obserwacji jest ograniczony, pole przypowierzchniowe pozostanie
niezmodyfikowane. W strefie przygranicznej wartości węzłowe będą polegać na interpolacji
pomiędzy wartościami NWP poza granicami Polski, a wartościami obserwacji naziemnych
w granicach kraju. Schemat interpolacji przedstawia rysunek 1.
4. System powinien mieć możliwość wyboru obszaru kraju, w którym zachodziłaby podmiana
parametrów przypowierzchniowych. W takim układzie tylko w zaznaczonym obszarze pole
przypowierzchniowe będzie pochodzić z obserwacji naziemnych, pozostała część pola
modelowego będzie zawierać czyste wartości parametrów NWP.
Rysunek 1. Schemat interpolacji pola obserwacji naziemnych wewnątrz kraju, NWP poza granicami
i obserwacyjno-modelowego w strefie przygranicznej.
Strona 31 z 33
5. System zapamięta wartości przypowierzchniowe, pochodzące z obserwacji, zachowując czysto
modelowe wartości na wyższych poziomach izobarycznych w osobnym kontenerze danych (plik
GRIB).
6. System automatycznie dokona przeliczenia parametrów wielowarstwowych takich jak: CAPE,
SHR (sfc-1km, sfc-3 km, sfc-6km), SRH (sfc-1 km, sfc-2 km, sfc-3 km), EHI. Kompletna lista
parametrów oraz algorytmy ich wyliczania zostaną dostarczone bezpośrednio do wykonawcy
przez zamawiającego.
Obserwacje przypowierzchniowe wykorzystywane do przeliczeń:
a) temperatura powietrza (2 m n.p.g),
b) wysokość punktu rosy (2 m n.p.g),
c) kierunek i prędkość wiatru (10 m n.p.g).
W celu dokonania podmiany, wartości temperatur oraz wiatru podlegać będą uśrednianiu do siatki
odpowiedniej dla modelu. Domyślnie interpolacja, zarówno pola dla wszystkich typów danych
NWP, jak i obserwacji naziemnych, prezentowana byłyby w siatce o rozmiarach 5x5 km.
Administrator systemu ma możliwość modyfikacji rozmiarów siatki dla każdego modelu
z osobna, jak również dla pola obserwacji. Metoda interpolacji polegać będzie na zastosowaniu
schematów takich jak: Kirging, Barnes, Cressman. Wybór konkretnej metody zostanie dokonany
podczas indywidualnej konsultacji zleceniodawcy i wykonawcy, jednak system będzie miał
możliwość stosowania, co najmniej dwóch schematów interpolacji, wybieranych na poziomie
panelu administracyjnego.
Pola wynikowe – prezentacja przeliczonych pól modelowych z możliwością nakładania konturów,
plik GRIB do archiwizacji.
Tak przetworzone pola, mają zastosowanie tylko w specyficznych praktykach i tylko przy
wyraźnym oznaczeniu, że jest to zmodyfikowane pole NWP, z parametrami przypowierzchniowymi
pochodzącymi z obserwacji naziemnych.
Strona 32 z 33
Załącznik nr 4
Moduł integracyjny
Zasilanie systemu danymi będzie realizowane przez moduł integracyjny. Moduł będzie się
integrował z Centralną Bazą Danych Operacyjnych (ogólnie: C2.6) z wykorzystaniem WebServices
(WS). Lista usług WS systemu C2.6 w skład, którego wchodzi CBDO znajduje się w załącznikach
nr 4.2 – 4.4.
Integracja związana z przesyłaniem dużych plików będzie oparta o warstwę plikową. Opis
przykładowej integracji z systemem C2.6 znajduje się w załączniku 4.1.
Administrator będzie miał możliwość konfigurowania:
- zakresu danych plikowych i relacyjnych dostępnych z CBDO,
- sposobu pobierania danych, tj. po zdarzeniu (zdarzenie na MQ) lub wg. Harmonogramu.
Strona 33 z 33

Załącznik nr 9 do SIWZ Opis Przedmiotu Zamówienia

Transkrypt

Podobne dokumenty

oferta_pracy_DNPM_ALADIN_23012017

regulamin uczestnictwa w projekcie

odp22 - Gmina Słomniki

pobierz formularz zamówienia

Instytut Zdrowia i Urody Barbara Salamandra ZO-05/16/4

pobierz zapytanie ofertowe