Jednolity Model Danych Interoperacyjność

Transkrypt

1 Jednolity Model Danych Interoperacyjność 1 Agenda: Wprowadzenie Cele Założenia Kontekst prac Przegląd produktów

2 Jednolity Model Danych O projekcie Wprowadzenie 2 Jednolity Model Danych, opracowany został w ramach projektu: Wypracowanie i wdrożenie innowacyjnych metod integracji danych katastralnych, mapy zasadniczej i Bazy Danych Topograficznych oraz modernizacja usług publicznych świadczonych przez Służbę Geodezyjną i Kartograficzną współfinansowanego z Mechanizmów Finansowych Europejskiego Obszaru Gospodarczego Zadanie: Prace eksperckie mające na celu opracowanie zintegrowanego modelu danych katastralnych oraz mapy zasadniczej, zaprojektowanie struktury bazy danych według przyjętego modelu danych, określenie niezbędnych standardów technicznych dla projektu, opracowanie zasad aktualizacji Bazy Danych Topograficznych danymi zawartymi w zintegrowanej bazie danych oraz przeprowadzenie szkoleń w tym zakresie

3 Jednolity Model Danych Szkolenie, dzień drugi Na jakim etapie szkolenia jesteśmy Wprowadzenie 3 1. Wprowadzenie 2. Interoperacyjność zbiorów danych przestrzennych 3. Przegląd Wyników Analizy Zasobów 4. Przegląd Specyfikacji OOP i OOG 5. Koncepcja identyfikatorów obiektów, wersjonowania, reguły nil reason 6. Przegląd specyfikacji modeli georeferencyjnych 7. Rekomendacja aktów prawnych, implementacja modelu, system zbierania uwag, kursy e-learning 8. Dyskusja i podsumowanie

4 Jednolity Model Danych Wprowadzenie Uczestnicy naszych prac 4 Kiedy mówimy nasze prace musimy mieć na myśli prace tak naprawdę całego środowiska geodezyjnego W pracach oprócz wykonawcy biorą udział przedstawiciele Zamawiającego Samorząd Województwa Mazowieckiego Biuro Geodety Województwa Mazowieckiego Główny Geodeta Kraju Miasto Płock Powiat Piaseczyński Eksperci recenzujący produkty, zgłaszający uwagi i wskazówki Państwo tu zebrani i ci, którzy wezmą udział w kolejnych szkoleniach, kursach e-learning, zgłoszą swoje uwagi za pośrednictwem systemu zgłaszania uwag

5 Jednolity Model Danych Wprowadzenie Etapy naszych prac 5 1. Opracowanie pierwszej wersji modelu Harmonizacja baz danych - doprowadzenie do ich wzajemnej spójności (eliminacja redundancji i niespójności) oraz przystosowanie do wspólnego i łącznego wykorzystywania 2. Konsultacje, zbieranie uwag 3. Wprowadzenie zmian do modelu danych i katalogu obiektów zarządzanych przez Służbę

6 Jednolity Model Danych Wprowadzenie Nasz model - Jednolity Model Danych 6 Jednolity Model Danych powstał w wyniku prac eksperckich. Jego opis to szereg dokumentacji, które omawiać będziemy dziś na kolejnych wykładach. Na samym początku, jako swego rodzaju wprowadzenie do wprowadzenia przez chwilę zatrzymajmy się nad znaczeniem poszczególnych składników nazwy Jednolity Model Danych Tak aby składał nam się w całość

7 Jednolity Model Danych Wprowadzenie Jednolity Model Danych 7 Takie same podejście do opisu różnych danych - w odniesieniu do tego jak powinny one być zbudowane, powiązane, opisane, udostępniane i interpretowane. Poszczególne rodzaje danych modelowano w oparciu o takie same generalne założenia w odniesieniu do analizy problemów i do syntezy wyników tej analizy. Określono ogólne i szczególne własności dla modelowanych danych. Na tej podstawie zdefiniowano klasy ogólne i szczegółowe. Powstały model składa się z różnych części, które powinny do siebie pasować i stanowić komplet - w odniesieniu do tego jakie zbiory danych chcemy scharakteryzować Opracowania szczegółowe korzystają z ogólnych i są ze sobą spójne, nie powinny pomijać istotnych danych ani opisywać ich wielokrotnie Jednolity sposób opisu różnych modeli schemat aplikacyjny, katalog obiektów itd. Ta jednolitość ma kluczowe znaczenie dla spójności samego modelu ale i spójności jego przyszłych implementacji.

8 Jednolity Model Danych Wprowadzenie Jednolity Model Danych 8 Co oznacza, że jest to model? Model System założeń, pojęć i zależności między nimi pozwalający opisać (zamodelować) w przybliżony sposób jakiś aspekt rzeczywistości. W przypadku systemów informatycznych model musi podkreślić te aspekty rzeczywistości, które są istotne dla uzyskania założonych celów, a może pominąć te w danym ujęciu nieistotne. Ten sam fragment rzeczywistości może być reprezentowany przez różne modele. Modele mogą być opracowane na różnym poziomie szczegółowości. Więcej o naszych celach oraz modelowanych przez nas aspektach rzeczywistości za chwilę

9 Jednolity Model Danych Wprowadzenie Jednolity Model Danych 9 Omawiany Model dotyczy DANYCH Nie jest to model oprogramowania, które, używając definicji z wikipedii, traktujemy jako całość informacji w postaci zestawu instrukcji, zaimplementowanych interfejsów i zintegrowanych danych przeznaczonych dla komputera do realizacji wyznaczonych celów. Zwracamy więc uwagę - nie opracowujemy w tym momencie specyfikacji programu(ów), który będzie nam służył do posługiwania się danymi. Nie wnikamy w technologie, jakich można by do tego użyć. Koncentrujemy się tylko i aż na tym, jakie są, jak są zorganizowane, jak powinny być interpretowane itd. DANE, które nas interesują. Więcej o tym jaki jest zakres modelowanych przez nas danych za chwilę

10 Jednolity Model Danych Mała dygresja ważne pojęcia Wprowadzenie 10 Dane Model danych Jeszcze tytułem wstępu spróbujmy rozróżnić kilka dodatkowych pojęć, których będziemy używać w trakcie naszych wykładów Baza danych Struktura Bazy Danych Usługa sieciowa Aplikacja Informacje Próba definiowania tych pojęć mogłaby prowadzić do wielogodzinnych dyskusji, nam chodzi tu o ujednolicenie naszego podejścia w trakcie omawiania produktów prac eksperckich Dlatego odwołamy się do możliwie krótkich opisów zaczerpniętych ze stron wikipedia.org

11 Jednolity Model Danych Wprowadzenie Pojęcia 11 Dane W najbardziej ogólnym systemowym sensie, dane "to wszystko co jest/może być przetwarzane umysłowo lub komputerowo". W tym sensie dane są pojęciem relatywnym, istnieją tylko razem z pojęciem przetwarzania i mogą przyjmować takie postaci jak: znaki, mowa, wykresy i sygnały. Różne dane mogą dostarczać tę samą informację, ale jednocześnie te same dane mogą też dostarczać różnych informacji. Z drugiej strony, np. zbiory liczb czy wyrazów mogą być danymi, ale jeśli nie wiemy co reprezentują to nie są informacją. (wikipedia) Czasem warto też rozważyć etymologię wyrazu

12 Jednolity Model Danych Wprowadzenie Pojęcia 12 Model danych Model danych to zbiór zasad, opisujących strukturę danych i dozwolone operacje poprzez specyfikację reprezentacji dozwolonych w modelu obiektów (klas) oraz ich związków. (wikipedia)

13 Jednolity Model Danych Wprowadzenie Pojęcia 13 Baza danych Baza danych to zbiór danych zapisanych w ściśle określony sposób w strukturach odpowiadających założonemu modelowi danych. W potocznym ujęciu obejmuje dane oraz program komputerowy wyspecjalizowany do gromadzenia i przetwarzania tych danych. Program taki (często pakiet programów) nazywany jest "Systemem zarządzania bazą danych" (ang. DataBase Management System, DBMS). W ścisłej nomenklaturze baza danych oznacza zbiór danych, który zarządzany jest przez system DBMS. (wikipedia)

14 Jednolity Model Danych Wprowadzenie Pojęcia 14 Struktura Bazy Danych Struktura - wzajemne powiązanie elementów, które stanowią całość i utworzona jest w określony sposób. Struktura bazy danych to jw.. ale dotyczy definicji danych, które tworzą bazę danych. (wikipedia)

15 Jednolity Model Danych Wprowadzenie Pojęcia 15 Usługa sieciowa Usługa sieciowa (ang. web service) komponent programowy niezależny od platformy i implementacji, dostarczający określonej funkcjonalności. Na bazie usług sieciowych można konstruować rozproszone systemy i aplikacje. Aplikacje komunikują się z usługami sieciowymi z wykorzystaniem internetowych protokołów i formatów danych. Protokołem najczęściej stosowanym do komunikacji z usługami sieciowymi jest SOAP, zatwierdzony przez organizację W3C. (wikipedia)

16 Jednolity Model Danych Wprowadzenie Pojęcia 16 Aplikacja Aplikacja - konkretny ze względu na oferowaną użytkownikom funkcjonalność element oprogramowania użytkowego, które jest podkategorią oprogramowania. Aplikacje to między innymi menedżery plików, oprogramowanie biurowe (edytory, arkusze kalkulacyjne, programy finansowe-księgowe, magazynowe, kadrowo-płacowe, itp.) oraz gry komputerowe, programy multimedialne i edukacyjne. (wikipedia)

17 Jednolity Model Danych Wprowadzenie Pojęcia 17 Informacje Informacja (łac. informatio - wyobrażenie, pojęcie) to pojęcie o wielu definicjach w różnych dziedzinach. Zasadniczo mamy dwa podstawowe punkty widzenia na informację. Pierwszy, który można nazwać obiektywnym i wywodzi się z fizyki i matematyki, gdzie informacja oznacza pewną własność fizyczną lub strukturalną obiektów, i drugi, subiektywny (kognitywistyczny), gdzie informacją jest to, co umysł jest w stanie przetworzyć i wykorzystać do własnych celów. (wikipedia) Dodatkowo pamiętamy z wcześniejszych slajdów, że informacje możemy, ale nie zawsze nam się to musi udać, wydobyć na podstawie danych np. używając do tego baz danych, znając ich struktury (a może i model), korzystając z aplikacji, które wywołają usługi sieciowe itp. Na pewno w trakcie wykładu spotkamy się jeszcze z innymi pojęciami, będziemy je na bieżąco wyjaśniać, żeby nie przeciążać tych początkowych slajdów

18 Jednolity Model Danych Ta sama rzeczywistość różne modele Wprowadzenie 18 Kończymy dygresję o pojęciach Jak już pisaliśmy - ten sam fragment rzeczywistości może być reprezentowany przez różne modele. Co jest istotne dla naszego modelu? Jakie są założenia do wytworzenia tego właśnie modelu? Jakie są główne cele naszych prac? Jakie przyjęliśmy założenia Jakie aspekty rzeczywistości modelujemy? Jaki zakres danych modelujemy? Jaki jest kontekst prac Jakie wymagania musimy uwzględnić na starcie? Jakie wyniki (produkty) chcemy uzyskać na końcu? Na te pytania postaramy się teraz odpowiedzieć

19 Jednolity Model Danych Cele Główne cele naszych prac 19 Przypomnijmy sobie, co jest celem całego Projektu Wypracowanie i wdrożenie innowacyjnych metod integracji danych katastralnych, mapy zasadniczej i bazy danych topograficznych Modernizacja usług publicznych świadczonych przez Służbę Geodezyjną i Kartograficzną. Co nam da Jednolity Model Danych (jest to jeden z produktów całego Projektu)? JMD pozwala wypracować i wdrożyć innowacyjne metody integracji danych katastralnych, mapy zasadniczej i bazy danych topograficznych, stanowi punkt wyjścia do modernizacji usług publicznych świadczonych przez Służbę Geodezyjną i Kartograficzną. Powinniśmy uzyskać podstawy do interoperacyjności danych w ramach Infrastruktury Informacji Przestrzennej. Na czym polega wypracowanie podstaw do interoperacyjności? Jak pokazać możemy tę ideę?

20 Idea interoperacyjności w ramach Krajowej IIP Jednolity Model Danych Cele 20 Rysunek poglądowy. Dla opracowanego modelu nie jest istotne na jakim poziomie jakie bazy są prowadzone. Bardziej szczegółowo o tych zagadnieniach na kolejnych wykładach Spróbujmy jeszcze uszczegółowić nasze cele

21 Jednolity Model Danych Cele Jeszcze o celach naszych prac Podsumowując cele prac eksperckich (które są częścią prac nad całym projektem i bezpośrednią przyczyną naszych szkoleń) to stworzenie podstaw do interoperacyjności określenie niezbędnych standardów technicznych dla projektu, 21 opracowanie jednolitego modelu danych zaprojektowanie struktury bazy danych według przyjętego modelu danych, opracowanie zasad logicznych i procedur organizacyjnych wymiany danych pomiędzy bazami danych z modelowanego zakresu Jakie założenia przyjęliśmy aby osiągnąć zamierzone cele?

22 Modelowane aspekty rzeczywistości Jednolity Model Danych Założenia 22 Modelujemy aspekty, które dotyczą danych zarządzanych i udostępnianych w ramach Infrastruktury Informacji Przestrzennej Zasadnicze założenie to modelowanie zagadnień związanych z informacyjnym punktem widzenia w rozumieniu normy Reference Model of Open Distributed Processing (RM-ODP, ITU-T Rec. X.901-X.904 ISO/IEC 10746). Co to takiego norma RM-ODP i jakie inne punkty widzenia wyróżniamy wg tej normy?

23 Dygresja na temat normy RM-ODP Jednolity Model Danych Założenia 23 Norma RM-ODP ma na celu usystematyzowanie wyników prac nad złożonymi systemami. W tym celu norma ta korzysta z tzw. punktów widzenia, które koncentrują się na różnych aspektach systemu. Specyfikacje opracowane z różnych punktów widzenia są powiązane i wzajemnie się uzupełniają. Wykorzystano materiały z Jakie jest znaczenie poszczególnych punktów widzenia wg tej normy?

24 Punkty widzenia wg normy RM-ODP Korporacyjny punkt widzenia. Jest najbardziej odgórny. Koncentruje się na strategicznych celach, zakresie, społecznościach korzystających z systemu. Określa biznesowe wymagania wobec systemu. Informacyjny punkt widzenia. Koncentruje się na tym jakie informacje obejmuje system, jak powinny być one usystematyzowane, zarządzane, interpretowane. Obliczeniowy punkt widzenia. Koncentruje się na dekompozycji funkcjonalności systemu. Inżynieryjny punkt widzenia. Koncentruje się na mechanizmach niezbędnych do zapewnienia pracy w środowisku rozproszonym. Technologiczny punkt widzenia. Koncentruje się na wyborze technologii (np. platforma sprzętowoprogramowa), która będzie optymalna dla systemu. Jednolity Model Danych 24 To dziś modelujemy! Wykorzystano materiały z Tego dziś nie modelujemy! Założenia Wracamy do modelowanych aspektów rzeczywistości

25 Jednolity Model Danych Modelowane aspekty rzeczywistości (cd.) Założenia 25 Modelujemy ogólne rozwiązania, które stanowić powinny fundament dla rozwoju bardziej szczegółowych modeli - Ogólny Obiekt Przestrzenny (OOP) Modelujemy bardziej szczegółowy ale wciąż ogólny: Ogólny Model Geodezyjny (OMG), obejmujący Ogólny Obiekt Geodezyjny (OOG) Występuje tu dziedziczenie własności OOG z OOP Modelujemy szczegółowe Modele Georeferencyjne, obejmujące poszczególne Obiekty Georeferencyjne Występuje tu dziedziczenie własności z OOP / OOG Jaki zakres danych musimy uwzględnić przy analizach?

26 Jednolity Model Danych Założenia Modelowany zakres danych 26 Jakie dane modelujemy w ramach ogólnego modelu geodezyjnego i modeli georeferencyjnych? Baza danych szczegółowych osnów geodezyjnych Baza danych ewidencji gruntów i budynków Baza danych geodezyjnej ewidencji sieci uzbrojenia terenu Baza danych obiektów topograficznych objętych zakresem treści mapy zasadniczej Baza danych obiektów topograficznych z numerycznym modelem rzeźby terenu Rejestr cen i wartości nieruchomości Bazy danych tematycznych prowadzonych przez Służbę Geodezyjną i Kartograficzną Model ogólny OMG obejmuje abstrakcyjne klasy obiektów. Modele georeferencyjne obejmują klasy, które są specjalizacją klasy OOG. Prace nasze prowadzą do powstania jednego, czy wielu modeli?

27 Jednolity Model Danych Założenia Jeden czy wiele modeli? 27 OOP OMG OOG Jednolity Model Danych (JMD) jest jeden. Częścią JMD jest specyfikacja klasy Ogólny Obiekt Przestrzenny (OOP) oraz Ogólny Model Geodezyjny (OMG), a także szczegółowe modele georeferencyjne. M-EGB Działka M- Specjalizacja poszczególnych części postępuje od góry do dołu rysunku. W formalny sposób pokazujemy te zależności przy pomocy pakietów UML

28 Jednolity Model Danych Założenia Jeden czy wiele modeli? 28 Pakiet JMD zawiera schematy aplikacyjne Jednolitego Modelu Danych. Zawiera on 2 pakiety dla klas ogólnych oraz 8 pakietów dla klas szczegółowych. Każdy z tych pakietów obejmuje definicję stosownego schematu aplikacyjnego. W razie rozszerzenia zakresu modelowanych danych zakłada się, że wewnątrz pakietu JMD wprowadzony będzie kolejny pakiet dla nowych klas szczegółowych. Pakiety ogólne nie powinny z tego powodu ulegać zmianom. Sprawdźmy jakie są zależności między pakietami

29 Zależności między pakietami Jednolity Model Danych Założenia 29 Co zawierają poszczególne pakiety sprawdzimy na kolejnych wykładach

30 Jednolity Model Danych Uwarunkowania początkowe Obowiązujace prawo Kontekst prac 30 Jakie są podstawy prawne istotne dla modelu? Ustawa Prawo geodezyjne i kartograficzne Rozporządzenie w sprawie ewidencji gruntów i budynków Rozporządzenie w sprawie szczegółowych zasad i trybu założenia i prowadzenia krajowego systemu informacji o terenie Rozporządzenie w sprawie szczegółowych zasad i trybu zakładania geodezyjnej ewidencji sieci uzbrojenia terenu oraz uzgodnień i współdziałania w tym zakresie Instrukcje Głównego Geodety Kraju w sprawie standardów technicznych dotyczących geodezji, kartografii oraz krajowego systemu informacji o terenie G-1, G-2, G-7 Wytyczne techniczne Głównego Geodety Kraju Instrukcja techniczna G-5, Baza Danych Topograficznych Dyrektywa Inspire; Prowadzimy działania projektowe w granicach i na podstawie prawa

31 Jednolity Model Danych Uwarunkowania początkowe. INSPIRE i zmiany prawne Kontekst prac 31 Uwzględniamy zasady i reguły zawarte w dyrektywie INSPIRE, oraz w projektach i wytycznych implementacyjnych do dyrektywy INSPIRE, a w szczególności: przechowywanie, udostępnianie oraz utrzymywanie i aktualizowanie danych przestrzennych powinno się odbywać na tym poziomie gdzie będzie to robione najefektywniej; powinno być możliwe łączenie w jednolity sposób danych przestrzennych pochodzących z różnych źródeł i wspólne korzystanie z nich przez wielu użytkowników i wiele aplikacji; powinno być możliwe łatwe wyszukiwanie danych przestrzennych oraz dokonywanie oceny ich przydatności dla określonego celu. Uwzględniamy projekt Ustawy o Infrastrukturze Informacji Przestrzennej Jeśli logika modelu poważnie cierpi z powodu obecnie obowiązujacych regulacji prawnych Rozważamy i rekomendujemy zmiany, jakie powinny być wprowadzone. Czy są realne? Jakie będą koszty? Powiązania z innymi regulacjami? Czas oczekiwania?

32 Uwarunkowania początkowe. Wymagania formalne Jednolity Model Danych Kontekst prac 32 Model musi zachować niezależność od środowiska komputerowego i struktury organizacyjnej (por. punkty widzenia RM-ODP) Model musi być oparty na standardach miedzynarodowych zdefiniowanych w normach ISO serii Model musi wspierać koncepcję jednolitego dla całego kraju systemu unikalnych i jednoznacznych identyfikatorów dla obiektów, zgodnych z architekturą proponowaną przez INSPIRE Model musi wspierać koncepcję opisu zmian stanu obiektów w czasie, w celu zapewnienia możliwości odtworzenia historii obiektu na dowolny moment Model musi wspierać koncepcję reguł wypełniania wartości atrybutów, w sytuacjach, gdy są one obligatoryjne, a nie jest możliwe ich wypełnienie Spełnienie tych wymagań ma kluczowe znaczenie dla zapewnienia interoperacyjności danych

33 Uwarunkowania początkowe. Wymagania organizacyjne Co jest istotne w organizacji prac, aby optymalnie wpasować się w rzeczywisty stan danych? Jednolity Model Danych Kontekst prac 33 1 Opieramy się na analizie zakresu tematycznego rejestrów i baz danych prowadzonych przez Służbę Geodezyjną i Kartograficzną, w odniesieniu do kompetencji samorządowej i rządowej administracji publicznej, oraz przedsiębiorstw i jednostek organizacyjnych gmin, powiatów, województw i Skarbu Państwa. Chcemy, aby opracowany model dawał się skonsumować, był realistyczny.

34 Uwarunkowania początkowe. Wymagania organizacyjne Co jest istotne w organizacji prac, aby optymalnie wpasować się w rzeczywisty stan danych? Jednolity Model Danych Kontekst prac 34 2 Zachowujemy zakres informacyjny danych w stosunku do obecnie prowadzonych baz danych, ale też eliminujemy zbędną redundancję danych we wszystkich bazach danych podlegających opracowaniu. Staramy się zidentyfikować znaczące atrybuty oraz usunąć nieistotne cechy obiektów w odniesieniu do danego modelu georeferencyjnego. Chcemy, aby opracowany model dawał się skonsumować, był realistyczny.

35 Uwarunkowania początkowe. Wymagania organizacyjne Co jest istotne w organizacji prac, aby optymalnie wpasować się w rzeczywisty stan danych? Jednolity Model Danych Kontekst prac 35 3 Zakładamy, jeśli tylko jest to realne, wykorzystanie przez poszczególne modele georeferencyjne Państwowego Rejestru Nazw Geograficznych jako głównego - źródła identyfikatorów nazw obiektów (w razie potrzeby rekomendując rozszerzenie PRNG), oraz rejestrów Państwowego Rejestru Granic PRG i TERYT. Chcemy, aby opracowany model dawał się skonsumować, był realistyczny.

36 Jednolity Model Danych Uwarunkowania początkowe. Wymagania organizacyjne Kontekst prac 36 Co jest istotne w organizacji prac, aby optymalnie wpasować się w rzeczywisty stan danych? 4 Określamy spójne wartości słownikowe w oparciu o obowiązujące akty prawne, wykorzystywane przez poszczególne modele georeferencyjne oraz pomiędzy modelami georeferencyjnymi. Chcemy, aby opracowany model dawał się skonsumować, był realistyczny.

37 Jednolity Model Danych Przegląd produktów Produkty prac eksperckich 37 Na koniec tej części wykładu chcemy określić w jakim kontekście powinniśmy czytać dokumentacje naszego modelu? Nie wszystkie analizowane zagadnienia są przecież opisane w jednej specyfikacji. Jest ona otoczona przez inne dokumentacje prac eksperckich. Na kolejnych slajdach przedstawiamy krótkie zestawienie tych dokumentacji Znajomość tego kontekstu powinna być bardzo pomocna przy przejściu do następnych wykładów

38 Jednolity Model Danych Przegląd produktów Jeszcze trzy ważne uwagi (1) 38 1) Będziemy wiele razy o tym przypominać w trakcie wykładów Model JMD żyje Prace nad ostateczną wersją dokumentacji jeszcze są w toku, a nasze szkolenia powinny zachęcić państwa do analizy tych dokumentów, zgłaszania uwag i sugestii dotyczących różnych produktów prac eksperckich. Nie da się bowiem w ciągu kilkunastu godzin szkoleń szczegółowo omówić, a tym bardziej dokładnie przeanalizować, tak ogromnego materiału Służyc nam może do tego celu system e-learning oraz system zgłaszania uwag, dostępne na stronach

39 Jednolity Model Danych Przegląd produktów Jeszcze trzy ważne uwagi (2-3) 39 2) Model JMD żyje komplet specyfikacji dostępny będzie na stronach jak tylko zakończy się trwający cały czas proces ostatecznej akceptacji przez Komitet Sterujący i grupę ekspertów Projektu publicznej wersji dokumentacji. 3) Należy też pamiętać, że z tego powodu możemy napotkać po jakimś czasie pewne fragmenty materiałów szkoleniowych, które stały się nieaktualne. Dlatego zwróćmy uwagę, że materiały z wszystkich dzisiejszych wykładów pokazują stan produktów na dzień Najważniejszym więc celem tych szkoleń jest pokazać JAK CZYTAĆ dokumentacje modelu, a nie próbować pokazać wszystko co w niej jest. Prześledźmy teraz jakie są produkty naszych prac

40 Jednolity Model Danych Przegląd produktów Produkty prac eksperckich (1) 40 Raport z analizy porównawczej Zawiera wynik analizy zakresu tematycznego rejestrów i baz danych prowadzonych przez Służbę Geodezyjną i Kartograficzną, w odniesieniu do kompetencji samorządowej i rządowej administracji publicznej, oraz przedsiębiorstw i jednostek organizacyjnych gmin, powiatów, województw i Skarbu Państwa Opracowując model opieramy się na tym raporcie. Omówimy ją za chwilę

41 Jednolity Model Danych Przegląd produktów Raport z analizy porównawczej 41 1 Definicje 2 Wstęp 2.1 Kontekst dokumentu 3 Stan obecny zakresu tematycznego rejestrów i baz danych prowadzonych przez Służbę Geodezyjną i Kartograficzną 4 Analiza aktów prawnych 5 Wnioski z analizy aktów prawnych 5.1 Proponowany zakres tematyczny rejestrów i baz danych prowadzonych przez Służbę Geodezyjną i Kartograficzną 5.2 Klasy i atrybuty uwzględnione (bądź uspójniane) w budowanym zintegrowanym modelu danych Opracowując model opieramy się na tym raporcie. Omówimy go w drugiej części wykładu

42 Jednolity Model Danych Przegląd produktów Produkty prac eksperckich (2) 42 Specyfikacja Ogólnego Obiektu Przestrzennego OOP opisanego w kategoriach geometrii i topologii, jakości danych, położenia, czasu, metadanych OO P To jedna z dokumentacji modelu JMD więcej na następnych wykładach

43 Jednolity Model Danych Przegląd produktów Produkty prac eksperckich (3) 43 Specyfikacja Danych dla Ogólnego Modelu Geodezyjnego Specyfikacja opisana w kategoriach geometrii i topologii, jakości danych, położenia, czasu, metadanych ogólna będąca generalnym przypadkiem odpowiednim dla baz georeferencyjnych OO P To jedna z dokumentacji modelu JMD więcej na następnych wykładach

44 Jednolity Model Danych Specyfikacja Danych dla Ogólnego Modelu Geodezyjnego Przegląd produktów 44 1 Definicje 2 Wstęp 2.1 Kontekst dokumentu 3 Ogólny model geodezyjny OO 3.1 OgolnyObiektGeodezyjny P 3.2 Schematy aplikacyjne 3.3 Katalog obiektów 3.4 Typy wyliczeniowe 3.5 Opis systemu referencyjnego 3.6 Opis kryteriów jakości danych 3.7 Metadane 3.8 Format wymiany GML (schematy aplikacyjne GML) 3.9 Zestaw testów sprawdzających zgodność zbioru danych ze specyfikacją 4 Podsumowanie To jedna z dokumentacji modelu JMD więcej na następnych wykładach

45 Jednolity Model Danych Przegląd produktów Produkty prac eksperckich (4) 45 Specyfikacje Danych dla poszczególnych modeli georeferencyjnych Specyfikacje opisane w kategoriach geometrii i topologii, jakości danych, położenia, czasu, metadanych dla analizowanych baz danych (GEOS, EGB, TBD ) OO P To jedna z dokumentacji modelu JMD więcej na następnych wykładach

46 1 Definicje 2 Wstęp 2.1 Kontekst dokumentu 3 Szczegółowy model georeferencyjny 3.2 Schematy aplikacyjne 3.3 Katalog obiektów 3.4 Typy wyliczeniowe 3.5 Opis systemu referencyjnego 3.6 Opis kryteriów jakości danych 3.7 Metadane 3.8 Format wymiany GML (schematy aplikacyjne GML) 3.9 Zestaw testów sprawdzających zgodność zbioru danych ze specyfikacją 4 Podsumowanie Jednolity Model Danych Specyfikacja Danych dla Ogólnego Modelu Georeferencyjnego OO P Przegląd produktów 46 To jedna z dokumentacji modelu JMD więcej na następnych wykładach

47 Jednolity Model Danych Przegląd produktów Produkty prac eksperckich (5) 47 Opis koncepcji identyfikatorów, wersjonowania, reguł nil reason ; zawiera opis i uzasadnienie: koncepcji jednolitego dla całego kraju systemu unikalnych i jednoznacznych identyfikatorów dla obiektów objętych opracowywanym modelem, koncepcji opisu zmian stanu obiektów w czasie; dla każdego typu obiektu opracowane zasady definiujące warunki zmiany wersji obiektu oraz zakończenia/rozpoczęcia jego cyklu życia, reguły dotyczące przypadków, w których podczas wypełniania poszczególnych wartości atrybutów obiektu nastąpi problem niemożności ich wypełnienia Model musi wspierać te koncepcje pasować do nich.

48 Jednolity Model Danych Przegląd produktów Produkty prac eksperckich (6) 48 Opis szczegółowej koncepcji interoperacyjności Zawiera opis koncepcji szczegółowych zasad logicznych i procedur organizacyjnych wymiany danych pomiędzy bazami danych z modelowanego zakresu Model musi wspierać tę koncepcję pasować do niej.

49 Jednolity Model Danych Przegląd produktów Produkty prac eksperckich (7) 49 Rekomendacje aktów prawnych Zawiera rekomendacje projektów aktów prawnych, dotyczących zmian wybranych przepisów technicznych i organizacyjnych prawa geodezyjnego i kartograficznego w celu dostosowania ich do potrzeb opracowanego modelu Jak już wspominaliśmy wcześniej - jeśli logika modelu poważnie cierpi z powodu obecnie obowiązujacych regulacji prawnych rozważamy i rekomendujemy zmiany, jakie powinny być wprowadzone.

50 Jednolity Model Danych Przegląd produktów Produkty prac eksperckich (8) 50 Opis wytycznych i zaleceń implementacji schematu aplikacyjnego w środowisku baz danych Zawiera opis wytycznych i zaleceń implementacji schematu aplikacyjnego w środowisku baz danych w odniesieniu do pozostałych dokumentów projektowych, z uzupełnieniem w razie potrzeby o dodatkowe wyjaśnienia. Jest to pomoc przy implementacji modelu.

51 Koncepcja interoperacyjności Agenda: 51 Wprowadzenie Założenia Zasady i procedury logiczne i organizacyjne zapewnienia interoperacyjności Przykłady Podsumowanie

52 Koncepcja interoperacyjności Szkolenie, dzień drugi Na jakim etapie szkolenia jesteśmy Wprowadzenie Wprowadzenie 2. Interoperacyjność zbiorów danych przestrzennych 3. Przegląd Wyników Analizy Zasobów 4. Przegląd Specyfikacji OOP i OOG 5. Koncepcja identyfikatorów obiektów, wersjonowania, reguły nil reason 6. Przegląd specyfikacji modeli georeferencyjnych 7. Rekomendacja aktów prawnych, implementacja modelu, system zbierania uwag, kursy e-learning 8. Dyskusja i podsumowanie

53 Koncepcja interoperacyjności Wprowadzenie Produkty prac eksperckich 53 Raport z analizy porównawczej Specyfikacja dla OOP Opis zasad interoperacyjności oraz opracowanie szczegółowych zasad logicznych i procedur organizacyjnych wymiany danych pomiędzy bazami danych Konsultacje środowiskowe Specyfikacja dla OMG Specyfikacja dla PMG Opis koncepcji identyfikatorów, koncepcji wersjonowania, koncepcji nil reason opis wytycznych i zaleceń implementacji schematu aplikacyjnego w środowisku relacyjnej lub relacyjno-obiektowej bazy danych oraz wymagań dla systemów zarządzania tymi bazami danych Rekomendacje aktów prawnych Koncepcja interoperacyjności jest jednym z produktów naszych prac Zaczynamy od niego, aby ułatwić czytanie pozostałych produktów

54 Koncepcja interoperacyjności Przypomnienie Główne cele naszych prac Wprowadzenie 54 Przypomnijmy sobie, co nam dać powinien Jednolity Model Danych? JMD pozwala wypracować i wdrożyć innowacyjne metody integracji danych katastralnych, mapy zasadniczej i bazy danych topograficznych, stanowi punkt wyjścia do modernizacji usług publicznych świadczonych przez Służbę Geodezyjną i Kartograficzną. Powinniśmy uzyskać podstawy do interoperacyjności danych w ramach Infrastruktury Informacji Przestrzennej. Interoperacyjność jest jednym z najważniejszych, a może najważniejszym celem, do którego dążymy. Spróbujemy przedstawić teraz jakie założenia przyjmujemy na naszej drodze do celu

55 Koncepcja interoperacyjności Założenia Co oznacza interoperacyjność 55 Interoperacyjność dla nas to: możliwość łączenia zbiorów danych przestrzennych oraz interakcji usług danych przestrzennych bez powtarzalnej interwencji manualnej w taki sposób, aby wynik był spójny a wartość dodana zbiorów i usług danych przestrzennych została zwiększona. Powróćmy teraz do diagramu pokazującego ideę interoperacyjności dla różnych zasobów PZGIK prowadzonych na różnych poziomach

56 Powracamy do diagramu idea Baza Danych Ogólnogeograficznych Baza Danych Topograficznych Zintegrowana powiatowa baza danych georefererencyjnych Baza Danych Obiektów Topograficznych Objętych Zakresem Mapy Zasadniczej Baza Danych Geodezyjnej Ewidencji Sieci Uzbrojenia Terenu Baza Danych Ewidencji Gruntów i Budynków Baza Danych Szczegółowych Osnów geodezyjnych KRAJ WOJEWÓDZTWO POWIAT Widzimy jak np. budynek z bazy EGIB przechodzi do bazy TBD a budynek z bazy TBD może zasilić bazę danych ogólnogeograficznych Widzimy przepływ informacji w drugą stronę W każdym zasobie chcemy mieć takie dane, które w innym nie występują, uzupełniają się, dają spójny wynik Koncepcja interoperacyjności Założenia Czego nam brakuje TERAZ, aby uzyskać interoperacyjność wg definicji podanej przed chwilą? 56 Diagram pokazuje nam interoperacyjność pomiędzy różnymi zasobami które mogą być prowadzone na różnych poziomach. Pokazujemy tylko zasoby PZGIK, chociaż definicja interoperacyjności daje tu miejsce wszystkim innym zasobom IIP

57 Koncepcja interoperacyjności Założenia Jak daleko do interoperacyjności 57 1 Możemy już teraz udostępniać dane z różnych zasobów PZGIK. I tak się dzieje Jeszcze nie ze WSZYSTKICH, ale z biegiem czasu Mogą być te dane wykorzystane do różnych celów Można próbować łączyć różne zbiory i integrować usługi możemy to zobaczyć np. na geoportal.gov.pl

58 Koncepcja interoperacyjności Założenia Jak daleko do interoperacyjności 58 2 Dla udostępnianych zasobów interwencja manualna może nie wymagać powtarzania (jak stabilne są pewne ustalenia?) Ale spodziewamy się konieczności interwencji manualnych przy korzystaniu z zasobów różnych dostawców (chociaż w sensie merytorycznym jest to taki sam zasób jak inny )

59 Koncepcja interoperacyjności Założenia Jak daleko do interoperacyjności 59 3 Możemy liczyć na to, że wynik będzie spójny dużo zależy tu od konfiguracji i wcześniej wspomnianych interwencji manualnych Zwróćmy też uwagę, że przytłaczająca większość integrowanych danych i usług opiera się o WMS W tym miejscu czujemy, że najbardziej powinniśmy liczyć właśnie na nasz model JMD!

60 Koncepcja interoperacyjności Założenia Jak daleko do interoperacyjności 60 4 Wartość dodana zbiorów i usług danych przestrzennych ulega zwiększeniu Możemy się zastanawiać jak mierzyć te zwiększanie się wartości ale na potrzeby tej akurat prezentacji intuicja podpowiada, że już teraz tak się dzieje Oczywiście zawsze może być lepiej Podsumujmy krótko to co przewinęło się na 4 ostatnich slajdach

61 Koncepcja interoperacyjności Założenia Jak daleko do interoperacyjności 61 Podsumowanie Wydaje się, że przybliżamy się do interoperacyjności, ale równocześnie ciągle brakuje nam wielu elementów do tego, aby osiągnąć to co przedstawia nasz ulubiony diagram ideowy Nie na wszystkie, ale na niektóre z tych elementów mamy wpływ właśnie teraz opracowując model JMD. Zebraliśmy warunki zapewnienia interoperacyjności prześledźmy je teraz pod kątem prac na modelem

62 możliwość łączenia zbiorów danych przestrzennych oraz interakcji usług danych przestrzennych Koncepcja interoperacyjności Założenia bez powtarzalnej interwencji manualnej Warunki interoperacyjności w taki sposób, aby wynik był spójny a wartość dodana zbiorów i usług danych przestrzennych została zwiększona. 62 Udostępnić dane, wyeliminować zbędne ograniczenia Zobowiązać do korzystania z danych tych, którzy powinni z nich korzystać Przeanalizować potrzeby i możliwości Przyjąć uniwersalne i otwarte standardy modelowania, udostępniania i opisu danych Opracować schematy aplikacyjne modeli danych i GML, katalog typów obiektów, które będą zarządzane i udostępniane, procedury organizacyjne wymiany danych Zaimplementować schematy aplikacyjne modelu baz danych i schematy GML Przypisać odpowiedzialność za poszczególne typy obiektów Wdrożyć procedury organizacyjne wymiany danych oraz dokonać koniecznych zmian aktów prawnych Jakie ma to znaczenie dla modelu danych?

63 Koncepcja interoperacyjności Założenia Jak zapewnić interoperacyjność 63 Kolorem czarnym zapisano warunki, które są bezpośrednio związane z modelem JMD (przypomnijmy sobie cele prac eksperckich ). Pozostałe są z nim powiązane - ale wymagają dodatkowych działań organizacyjnych i technicznych. W takim razie przeanalizujmy wyniki naszych prac pod kątem interoperacyjności

64 Podstawy interoperacyjności danych dla baz georeferencyjnych Koncepcja interoperacyjności Zasady i procedury 64 Wykorzystanie Produktów Projektu 1. Wykorzystanie rekomendacji w zakresie zamian przepisów prawnych i regulacji technicznych 2. Utworzenie baz danych georeferencyjnych w oparciu o zdefiniowane modele georeferencyjne 3. Implementacja schematu aplikacji w środowisku relacyjnej bazy danych zgodnie z opisanymi wytycznymi i zaleceniami implementacji 4. Gromadzenie danych w zasobach georeferencyjnych oraz ich identyfikacja i wersjonowanie zgodnie z jednolitymi zasadami opisanymi koncepcji identyfikatorów, wersjonowania, reguł "nil reason. 5. Wszystkie obiekty składające się na bazy infrastruktury informacji przestrzennej oparte powinny być o Ogólny obiekt przestrzenny, który stanowi uogólnienie wszystkich obiektów posiadających lokalizację przestrzenną. Stanowi on równocześnie podstawę zasady zachowania referencyjności obiektów we wszystkich modelach georeferencyjnych, a to dalej stanowi podstawę fundamentalnego zachowania interoperacyjności wszystkich baz danych. Wymienione tu produkty będziemy jeszcze szczegółowo omawiać Teraz przeanalizujmy podstawowe zasady interoperacyjności z nich wynikające...

65 Koncepcja interoperacyjności Zasady i procedury Rozważmy ogólne wnioski z analizy 65 Modelując działamy w pewnej sytuacji prawnej, organizacyjnej, technologicznej Dążymy do tego, aby nasz model mógł być zaimplementowany przy rozsądnym wykorzystaniu czasu, sił i środków Oznacza to, że model musi być REALISTYCZNY Dążymy do tego, aby nasz model był możliwie niezależny od zmian tej sytuacji chcemy, aby zarówno w obecnej sytuacji jak i w wypadku jej zmian sam model był spójny i jednolity Oznacza to, że model musi być w pewnym sensie IDEALISTYCZNY Musimy pogodzić te dwa fakty, przyjąć pewne kompromisy

66 Koncepcja interoperacyjności Zasady i procedury Modelując myślimy o interoperacyjności 66 Ideał Jak sobie powiedzieliśmy, w każdym zasobie funkcjonującym w ramach IIP chcemy mieć takie dane, które w innym nie występują, uzupełniają się, dają spójny wynik Realizm Powiedzieliśmy sobie też, że możemy już teraz udostępniać dane z różnych zasobów PZGIK i wykorzystywać je do różnych celów. I że tak się dzieje W tej chwili jednak nie dadzą nam one spójnego wyniku. Nie są one ze sobą zharmonizowane. W takim razie czas na harmonizację

67 Harmonizacja Koncepcja interoperacyjności Zasady i procedury 67 Popularne ostatnio słowo harmonizacja lub też brak harmonizacji można sobie skojarzyć z harmonią albo i akordeonem Żeby zagrać dobry koncert wszystkie nutki powinny zabrzmieć wtedy kiedy jest ich czas i na takiej wysokości jaką jest dla nich przewidziana Tu mamy nasz problem

68 Harmonizacja Koncepcja interoperacyjności Zasady i procedury 68 W różnych zasobach PZGIK wystąpić mogą teraz obiekty reprezentujące te same obiekty świata rzeczywistego. Powstaje redundancja. Obiekty redundantne mają częściowo takie same, częściowo różne atrybuty, różne pochodzenie, aktualność, wiarygodność Często nie wiemy jak je identyfikować, wiązać ze sobą, które z nich mogą stanowić geo-referencję Możemy czasem uznać, że redundancja jest potrzebna, wręcz korzystna. Warto rozważyć czy tak jest rzeczywiście. Czasem możemy nie mieć wątpliwości, że redundancja jest zbędna - wynika tylko z pewnych uwarunkowań, które moglibyśmy zmienić z korzyścią dla wszystkich Zatrzymajmy się zatem na chwilę nad przykładem takich sytuacji

69 Obiekty identyfikacja, powiązania, redundancje Koncepcja interoperacyjności Zasady i procedury 69 Powiązanie między obiektami Redundancja? Identyfikacja Reprezentacja Obiekt Przestrzenny Jako koronny przykład problemów związanych z identyfikowaniem obiektów, powiązaniami między obiektami, redundancji danych rozważmy sprawę budynku. EGB: Budynek B1? TBD: Budynek B2 Do wstępnych założeń projektowych musimy więc dodać nowe wnioski wynikające z naszej analizy: jak TO zamierzamy modelować? Obiekt świata rzeczywistego Przeanalizujmy tę sytuację nadal pozostając na możliwie ogólnym poziomie

70 Obiekty identyfikacja, powiązania, redundancje Koncepcja interoperacyjności Zasady i procedury 70 EGB: Budynek B1? TBD: Budynek B2 Przypomnijmy - modelujemy rzeczywistość w tym projektujemy klasy: typy obiektów przestrzennych, które są odpowiednie do zaprezentowania obiektów świata rzeczywistego w modelu JMD. To obiekty przestrzenne a więc te, które reprezentują obiekt świata rzeczywistego posiadają swój identyfikator (obok, na rysunku oznaczony jako B1, B2) i o takiej identyfikacji chcemy dalej mówić. Nie będziemy rozważać jak zidentyfikować sam obiekt świata rzeczywistego nie jest to nam potrzebne! Czy to, że ten sam obiekt świata rzeczywistego jest różnie reprezentowany przez różne obiekty przestrzenne jest z założenia złe?

71 Obiekty identyfikacja, powiązania, redundancje Koncepcja interoperacyjności Zasady i procedury 71 EGB: Budynek B1? Zabytki: Budynek B2 Jeżeli reprezentujemy obiekt świata rzeczywistego w całkiem różnych celach można uznać, że taka różna zdublowana reprezentacja jest czymś normalnym. Bo modelujemy rzeczywistość mając różne cele potrzebujemy różniących się atrybutów itd..

72 Obiekty identyfikacja, powiązania, redundancje Koncepcja interoperacyjności Zasady i procedury 72 Na naszym rysunku wstawiamy więc w miejsce bliżej niezdefiniowanego zasobu Zabytki zasób TBD. Zarówno EGIB jak i TBD są w naszym zasięgu EGB: Budynek B1? TBD: Budynek B2 Możemy zdefiniować powiązanie między takimi obiektami przestrzennymi przez wykorzystanie swego rodzaju rejestru powiązań obiektów (Referencje: PowiazanieObiektow[0..*] - szczegóły na następnym wykładzie). Rejestr taki pozwala zapisać wiele powiązań dla każdego z obiektów używając identyfikatorów obiektów. Powiązania są definiowane przez wartość identyfikatora obiektu źródłowego, wartość identyfikatora obiektu zależnego, nazwę powiązania. Wiemy jak zapisać powiązanie obiektów. Nie jest to jednak próba eliminowania redundancji!

73 Obiekty identyfikacja, powiązania, redundancje Koncepcja interoperacyjności Zasady i procedury 73 Usuwanie ZBĘDNEJ redundancji. Kiedy uznajemy, że w modelu wprowadziliśmy redundancję w zakresie klas? Dla reprezentacji takich samych obiektów świata rzeczywistego zamodelowaliśmy różne klasy i widzimy, że mają one wiele wspólnych cech, a my zamierzamy dla każdej z nich tworzyć instancje obiektów. Zgadzamy się, że zbędną redundancję należy usunąć? Jak określić, kiedy redundancja jest niezbędna i nie powinniśmy jej usuwać że jest to mniejsze zło, czy że jest to wręcz zaleta? Możemy rozważać względy wydajności, bezpieczeństwa, logiki. Dwa pierwsze aspekty pomijamy na tym etapie przyjmijmy na razie, że modelujemy idealną sytuację, problem wydajności i bezpieczeństwa rozwiążemy na poziomie inżynieryjnego i technologicznego punktu widzenia. Co w takim razie z logiką modelu?

74 Obiekty identyfikacja, powiązania, redundancje Koncepcja interoperacyjności Zasady i procedury 74 Czy w takim razie chcemy, żeby w modelu znalazły się dwie klasy dla reprezentacji takich samych obiektów świata rzeczywistego? Czy dopuszczamy redundancję? Tak jak mówiliśmy to zależy od różnic w tej reprezentacji Nawiązując do przykładu z rysunku na poprzednim slajdzie czy modelujemy tak, że budynek reprezentowany będzie przez obiekt w bazie EGB a równocześnie ten sam budynek będzie reprezentowany przez obiekt w bazie TBD? Stwierdzamy w wyniku analiz, że jest to przypadek redundancji, której nie powinniśmy eliminować: Budynki w EGIB odpowiadają stanowi prawnemu Budynki w TBD odpowiadają stanowi w terenie Zastosowanie tych danych może być różne Jakie są tego konsekwencje

75 Koncepcja interoperacyjności Zasady i procedury Pozostawione redundancje 75 Gdy pozostawiamy redundancję dla pewnych klas musimy zadbać o zharmonizowanie ich atrybutów. Czy potrzebujemy podobnych atrybutów w obydwu klasach? Jeśli tak niech ich znaczenie będzie ze sobą zgodne pod względem typu danych, zasad wypełniania i interpretacji Na przykład funkcja budynku, która jest typu wyliczeniowego, niech ma takie same wartości dopuszczalne w obydwu klasach Dzięki identyfikatorom jednoznacznie rozpoznamy każdy obiekt, dzięki referencjom sukcesywnie powiążemy między sobą obiekty reprezentujące te same obiekty świata rzeczywistego. Redundancja, która jest uzasadniona stanie się uporządkowana, przewidywalna, zarządzalna i wytłumaczalna. Czy dużo klas redundantnych pozostawiono?...

76 Pozostawione redundancje i harmonizacje Koncepcja interoperacyjności Zasady i procedury 76 Staraliśmy się pozostawić jak najmniej redundancji. Dla budynku pomijamy modelowanie go np. w bazie danych topograficznych treści mapy zasadniczej (pakiet BDOTMZ będzie na kolejnych wykładach). Mamy go w ramach EGIB. Szczegółowe informacje o tych zagadnieniach, zastosowanych sposobach harmonizowania poszczególnych klas znajdują się w raporcie z analizy porównawczej, którą omawiać będziemy już w następnej części wykładu Zbierzmy w takim razie zasady zapewnienia interoperacyjności

77 Zasady zapewnienia interoperacyjności danych (1) Koncepcja interoperacyjności Zasady i procedury Zasoby danych, dla których opracowano modele danych w ramach Projektu stanowią fundament zasobów infrastruktury danych przestrzennych. 2. Georeferencyjne bazy danych i zasoby objęte Projektem prowadzone są z wykorzystaniem systemów dziedzinowych np. baza georeferencyjna EGiB prowadzona jest z wykorzystaniem systemu informatycznego, w którym zaimplementowano funkcje, procedury i interfejsy pozwalające na gromadzenie, aktualizację i udostępnianie danych ewidencji gruntów i budynków. 3. Bazy GEOS, EGiB, RCiWN, GESUT oraz BDOTMZ (i systemy służące do ich prowadzenia) wzajemnie się uzupełniają gromadząc i przedstawiając najbardziej dokładną informacją o przestrzeni dla ściśle określonego i pokrywającego się obszaru. 4. Baza TBD i Bazy tematyczne cechuje inny poziom szczegółowości informacji o przestrzeni, a podstawą dla nich są dane GEOS, EGiB i BDOTMZ. 5. Bazy GEOS, EGiB, GESUT i BDOTMZ stanowią komponent podstawowy danych przestrzennych.

78 Zasady zapewnienia interoperacyjności danych (2) Koncepcja interoperacyjności Zasady i procedury Zasoby danych objętych Projektem gromadzone są w ujednoliconych strukturach danych, w oparciu o modele danych wypracowane w ramach projektu - oparte o normy ISO serii Gromadzenie danych, a także ich udostępnianie i wymiana odbywa w bazach danych zgodnych z zaleceniami i wytycznymi określonymi w ramach Projektu. 8. Dla każdego zasobu, bazy danych prowadzony jest katalog metadanych, który jest podstawą informacji o zasobie. Stanowi również podstawę udostępniania danych i wymiany informacji pomiędzy systemami. 9. W zasobach dane gromadzone są wg ujednoliconych zasad nadawania identyfikatorów. 10. Za prowadzenie i aktualizację zasobów danych georeferencyjnych odpowiadają instytucje i jednostki organizacyjne (podmioty prowadzące), których zakres działania, status, zdolności merytoryczne i prawne, a także obowiązki wynikające z określonych przepisów prawa nakazują prowadzenie tych zasobów

79 Zasady zapewnienia interoperacyjności danych (3) Koncepcja interoperacyjności Zasady i procedury Podmiot prowadzący tworzy lokalne centrum interoperacyjności tworzy systemy i zasoby, aktualizuje zasoby, a także udostępnia usługi zapewniające dostęp do danych jego systemów. 12. Podmioty prowadzące udostępniają dane zgodnie z obowiązującymi przepisami prawa. 13. Wymiana danych pomiędzy systemami następuje na poziomie wymiany informacji i na poziomie usług w oparciu o standardy wymiany informacji i wymiany usług sieciowych. 14. Informacje z zasobów georeferencyjnych udostępniane są innym systemom, a także innym odbiorcom informacji nie tylko poprzez usługi sieciowe i sam przepływ informacji, ale również projekcję zasobu lub fragmentu zasobu w postaci klasycznego opracowania kartograficznego. 15. Projekcja kartograficzna realizowana jest przez system poprzez zasady opisane w modelach kartograficznych. Uszczegółowimy teraz te ogólne zasady

80 Uszczegółowienie zasad interoperacyjności (1) Koncepcja interoperacyjności Zasady i procedury Każdy obiekt wprowadzany jest do bazy danych tylko raz, nie wykonuje się jego kopii (repliki) i innym zasobie np. jeżeli punkt osnowy został wprowadzony do bazy danych GEOS nie wprowadza się go ponownie do EGiB, BDOTMZ, czy bazy TBD (pamiętajmy, że zajmujemy się informacyjnym punktem widzenia, pomijamy tu technologiczny punkt widzenia, w ramach którego mogą być budowane na niższym poziomie rozwiązania buforujące, itp..). 2. Docelowo wymiana danych i integracja systemów baz danych georeferencyjnych następuje on-line np.: a) System EGiB łączy się z bazą BDOTMZ połączeniem tylko do odczytu dla pokazania elementów BDOTMZ związanych z obiektami EGiB, b) System BDOTMZ łączy się z GESUT i EGiB połączeniem tylko do odczytu dla pokazania warstwy ewidencji gruntów i budynków oraz ewidencji uzbrojenia terenu.

81 Uszczegółowienie zasad interoperacyjności (2) Koncepcja interoperacyjności Zasady i procedury Komunikacja i współdziałanie zapewniające wymianę danych pomiędzy bazami danych georeferencyjnych odbywa się na dwóch poziomach: a) Na poziomie przepływu informacji pomiędzy systemami, gdzie systemy zapewniają przepływ informacji pomiędzy wszystkimi uczestnikami procesów decyzyjnych i administracyjnych (a więc pomiędzy innymi systemami, ale i np. wykonawcami geodezyjnymi), b) Na poziomie usług INSPIRE, usług sieciowych (architektura SOA) wystawionych przez każdy system.

82 Uszczegółowienie zasad interoperacyjności (3) Koncepcja interoperacyjności Zasady i procedury Aktualizacja baz danych georeferencyjnych odbywać się może na podstawie dokumentów zapewniających odpowiednią jakość i wiarygodność danych (np. wyniki prac geodezyjnych, czy akty notarialne) lub też poprzez aktualizację zasobu jednej bazy danych na podstawie zasobu innej bazy (np. z wykorzystaniem procedur generalizacji). 5. Bazy danych, dla których podstawą aktualizacji jest ten sam dokument zmiany lub zbiór dokumentów współpracują ze sobą poprzez systemy informatyczne służące do ich prowadzenia i udostępniane przez nie usługi INSPIRE. 6. Komunikacja i współdziałanie pomiędzy bazami danych georeferencyjnych objętych projektem i systemami Informatycznymi służącymi do prowadzenia tych zasobów odbywa się w wykorzystaniem usług INSPIRE udostępnianych przez każdy system.

83 Uszczegółowienie zasad interoperacyjności (4) Koncepcja interoperacyjności Zasady i procedury Usługami INSPIRE są: a) Usługi ładowania danych, b) Usługi pobierania danych, c) Usługi wyszukiwania danych, d) Usługi przeglądania danych, e) Usługi transformacji danych, f) Usługi wywoływania usług danych przestrzennych.

84 Uszczegółowienie zasad interoperacyjności (5) Koncepcja interoperacyjności Zasady i procedury Zasób bazy danych EGiB i BDOTMZ stanowi podstawę aktualizacji TBD, a fundamentem takiej aktualizacji jest: a) jednolity sposób i system identyfikacji obiektów, b) standaryzacja struktury danych zasobów, c) stosowanie ujednoliconych słowników dla obiektów tego samego typu w zasobach składających się na komponent podstawowy danych infrastruktury przestrzennej (GEOS, EGiB, GESUT, BDOTMZ) i zasobach TBD i map tematycznych lub reguł konwersji słowników, gdy te sam obiekty w różnych zasobach nie są oparte o te same słowniki. 9. Aktualizacja TBD odbywa się poprzez protokoły różnicowe wspomagane procesami generalizacji i przetwarzania obiektu na odpowiednią skalę i stosowanie do potrzeb zależnych od różnic prezentacji kartograficznej obiektów w różnych zasobach. Rozpatrzymy teraz przypadki interoperacyjności pomiędzy bazami georeferencyjnymi

85 Interoperacyjność EGiB GESUT BDOTMZ GEOS Koncepcja interoperacyjności Zasady i procedury BDOTMZ stanowi uzupełnienie zasobu EGiB, GESUT i GEOS o elementy nie zdefiniowane w tych zasobach. 2. W systemie służącym do prowadzenia EGiB istnieje możliwość wyświetlanie danych ewidencji gruntów i budynków na tle danych pochodzących z zasobów bazy BDOTMZ, GEOS i GESUT. System EGiB łączy się z systemami BDOTMZ, GEOS i GESUT połączeniem tylko do odczytu. 3. W systemie służącym do prowadzenia GEOS istnieje możliwość wyświetlanie danych osnów geodezyjnych na tle danych pochodzących z zasobów bazy EGiB, GEOS i GESUT. System GEOS łączy się z systemami EGiB, BDOTMZ i GESUT połączeniem tylko do odczytu. Przykładowa sytuacja