Wybrane aspekty projektowania systemów zarządzania wielorozdzielczą bazą danych topograficznych Miłosz Gnat Dariusz Gotlib Warszawa, 8 kwiecień 2011.

Prezentacja na temat: "Wybrane aspekty projektowania systemów zarządzania wielorozdzielczą bazą danych topograficznych Miłosz Gnat Dariusz Gotlib Warszawa, 8 kwiecień 2011."— Zapis prezentacji:

1 Wybrane aspekty projektowania systemów zarządzania wielorozdzielczą bazą danych topograficznych
Miłosz Gnat Dariusz Gotlib Warszawa, 8 kwiecień 2011

2 Stosowane pojęcia i skróty
BDT = TBD = BDOT SZBDT=SZTBD=SZBDOT Definicja z Wytycznych technicznych „Baza Danych Topograficznych (TBD): Pod pojęciem „System informatyczny zarządzania TBD” rozumie się zespół oprogramowania i sprzętu pozwalający na sprawne i zgodne z odpowiednimi wytycznymi zarządzanie zasobem TBD w tym m.in. kontrolę przyjmowanych do zasobu danych, udostępnianie danych, dostarczanie mechanizmów poprawnej aktualizacji danych, zapewnienie bezpieczeństwa danych wizualizację podstawowe analizy danych

3 Schemat Przepływu Danych BDT

4 Dokumentacja Systemu Informatycznego Zarządzania BDT

5 System Informatyczny Zarządzania BDT - FUNKCJE

6 System Informatyczny Zarządzania BDT - FUNKCJE

7 System Informatyczny Zarządzania BDT - PROCES AKTUALIZACJI DANYCH

8 Specyfika zarządzania wielorozdzielczymi bazami danych

9 SZWBDT – kluczowe pytania w kontekście projektu systemu
Czy cała produkcja, aktualizacja, przetwarzanie tylko siłami firm komercyjnych? Czy jeden system centralny, w jednym środowisku aplikacyjnym, czy wiele systemów lokalnych Baza zasób centralny System zarządzania System zarządzania Aktualizacja Aktualizacja Baza zasób centralny Wykonawca Wykonawca poziom centralny Jak wiadomo trwają prace na rozwojem koncepcji Georeferencyjnej Bazy Danych Obiektów Topograficznych jako bazy wielorozdzielczej. Do jej obsługi niezbędne będzie zbudowanie systemu zarządzania, który będzie pozwalał w sprawny sposób z niej korzystać. Chciałbym w tym miejscu wskazać kilka aspektów projektowania takiego systemu. (Po co ?...) Projektant systemu będzie miał do rozważenia kilka koncepcji. Różnią się strukturą organizacji, możliwymi składnikami bazy, kosztami i czasem wdrożenia. Chcąc taki system zaprojektować dobrze, trzeba najpierw, na szczeblu decyzyjnym odpowiedzieć sobie na dwa podstawowe pytania. Czy cała produkcja, aktualizacja, wizualizacja, przetwarzanie tylko siłami firm komercyjnych? Do Darka G. – jak jest właściwie alternatywa? Czy jeden system centralny, w jednym środowisku z dostępem regionalnym, czy wiele systemów lokalnych [Jaka ma być organizacja zarządzania bazą? Czy będzie to baza centralna, którą traktujemy tylko jako magazyn? Gdzie każda większa operacja (aktualizacja, generalizacja) wiąże się z koniecznością wydania porcji danych na zewnątrz, gdzie moduły produkcji DCM, wizualizacji, wyszukiwania są realizowane na jej kopiach wydawanych co jakiś czas do województw.. (nie dyskutuję tu o powodach przyjęcia takiego modelu) A może zostanie przeforsowany model bazy centralnej, w którym moduły funkcjonalne operują na jej głównym zasobie (a nie jakiś replikach). Edycja odbywa się zdalnie, każda aktualizacja jest momentalnie widziana w systemie. Zalety: - prosta (scentralizowana) architektura systemu informatycznego – możliwość dobrego zdefiniowania odpowiedzialności za zarządzanie systemem – wysoki poziom bezpieczeństwa – wysoki stopień spójności danych Wady: - Potrzebne będą niezawodne łącza i mechanizmy kontroli transakcji on-line W tym referacie kilkakrotnie pojawi się odwołanie do konsekwencji wyborów podjętych na tym etapie. Baza kopia regionalna wizualizacja udostępnianie wyszukiwanie wizualizacja udostępnianie wyszukiwanie System zarządzania poziom lokalny

10 SZBDT a SZWBDT – różnice wpływające na proces projektowania
Sposób konstrukcji bazy danych Procesy aktualizacji Procesy generalizacji Procesy wizualizacji Złożoność zasobu danych Niezależnie od tego, jakie będą odpowiedzi na powyższe pytania jest temat do rozważenia, który chciałbym przedstawić. Temat różnic, jakie w proces projektowania Systemu Zarządzania wywołuje Wielorozdzielczość bazy. Na początku wspomniałem, że istnieją wytyczne do projektowania SZBDT. System Zarządzania WBDT będzie do niego w niektórych aspektach podobny, jednak w większości aspektów będzie bardziej skomplikowany. Inna będzie konstrukcja bazy danych Inne – bardziej skomplikowane - będą moduły odpowiadające za aktualizację, wizualizację, wyszukiwanie, produkcję map DCM Dojdzie moduł generalizacji. Generalizacja to integralny element systemu zarządzania wielrozdzielczą bazą danych; służy do tworzenia, aktualizacji jednej z części systemu, a nie produktów pochodnych – wydawanych na zewnątrz. Ogromne więc jest jego znaczenie. System Zarządzania będzie musiał poradzić sobie z bazą, która będzie dużo bardziej złożona od BDOT. Nie da się tego wykonać bez systemu wspomagania decyzji opartego o zestaw metadanych bogatszy, niż w SZBDT.

11 KONSTRUKCJA BAZY DANYCH
DCM1000 DCM500 DLM250 DLM50 EuroGraphics DCM250 poziom skalowy DLM100 DCM100 DCM50 Spójrzmy na konstrukcję bazy danych: Na schemacie posługuje się skrótami: DLM = Digital Landscape Model (rzeczywiste położenie obiektów) DCM = Digital Cartographic Model (położenie obiektów poddane redakcji kartograficznej) W SZBDT była tylko baza poziomu Obok niej był jeszcze komponent KARTO. Zasadnicza konepcja konstrukcji Wielorozdzielczej Bazy Danych jest taka: Mamy kilka poziomów skalowych, jakim odpowiadają dane zawarte w bazie. Na poziomie najniższym mamy bazę georeferencyjną DLM10 Na poziomie wyższym jest baza DLM250. odpowiednik dawnej BDO. Baza referencyjna jest podstawą do tworzenia baz pochodnych do celów produkcji opracowań kartograficznych w skalach dużych i średnich. Możliwe są tu różne scenariusze generowania produktów pośrednich. Można także przyjąć, ze dla specjalnych celów generowana z DCM50 będzie DLM50. Baza poziomu wyższego jest źródłem danych dla małoskalowych opracowań kartograficznych. Jest także źródłem do opracowań europejskich. DCM25 DLM10 DCM10 Referencyjna baza danych topograficznych Mapy topograficzne i przeglądowe Produkty pochodne – na zamówienie

12 KONSTRUKCJA BAZY DANYCH - sposób „wiązań” między poziomami
Docelowo – jedna baza danych, poziom DLM250 generowany z DLM10 Łatwiejsze budowanie połączeń – powstają w procesie generowania warstwy wyższej Okres przejściowy – dwie bazy danych DLM10 i DLM250 integrowane ze sobą Adaptacja BDO jako warstwy małoskalowej MRDB Trudne budowanie połączeń między warstwami w procesie wyszukiwania związków między obiektami generowanie warstwy wyższej DLM10 tabele połączeń DLM250 1. Istnieje możliwość, że przez pewien czas współistnieć będą DLM10 – pochodna TBD i BDO – baza realizowana, wg zupełnie innej koncepcji. Można rozważyć opcję uznania BDO za wyższy LoD w MRDB. Konsekwencją tego jest konieczność zlinkowania obiektów z tych warstw. Proces teoretycznie możliwy, ale ze względu na koszty - powieść sci-fi. 2. Realnym rozwiązaniem jest dalsze korzystanie w zakresie potrzeb małoskalowych z BDO i oczekiwanie na moment, kiedy będzie można zbudować DLM250. Do tego potrzebne będą: - dane DLM10 zawierające dla odpowiednich obszarów wypełnione warstwy dodatkowe - Struktura bazy przygotowana na wprowadzenie rekordów linkujących - System generalizacji danych Wielką zaletą tego rozwiązania jest fakt, że tworzenie powiązań będzie integralną częścią procesu generowania bazy wyższego poziomu. tworzenie połączeń DLM10 tabele połączeń DLM250 BDO

13 KONSTRUKCJA BAZY DANYCH - sposób „wiązań” między poziomami
Wariant bottom-up z użyciem dodatkowych atrybutów (relacja n:1) Załóżmy, że przyjmie się wariant budowy MRDB w proponowanym kształcie, czyli DLM10 jako baza referenyjna, DLM250 jako baza pochodna, obie połączone systemem powiązań. Jaki to powinny być wiązania? Dlaczego właśnie bottom-up? Wariant atrybutowy jest zbyt skomplikowany i daje za mało możliwości. Wszystkie dane mogą być zapisane razem, a o tym, do jakiego LOD należą decyduje specjalny atrybut. Atrybut tez opisuje w jaki sposób danych obiekt ma wyglądać na zadanym LOD (i to właśnie jest skomplikowane). Nie ma zapisanych relacji między postaciami danego elementu rzeczywistości z różnych LOD. Wydanie części takiego zbioru jako DLM10 na zewnątrz to SciFi. Wariant top-down generuje wiele rekordów z pustymi polami, więc jest nieefektywny z punktu widzenia wydajności. (trochę tego nie widzę, ale tak piszą Hempe i Sester i wszyscy za nimi powtarzają) Jest możliwy do wykonania tylko w formie dodatkowych tabel linków. Nie można jednemu rekordowi z niższego LoD dopisać w jednej kolumnie wszystkich ID rekordów z nim związanych na wyższym LoD (tzn., dałoby się np., formie stringa z listą ID rodzielonych jakimś znakiem, ale to pomysł kiepski ) Wariant bottom-up pozwala łatwo i wydajnie określić relacje między postaciami danego elementu rzeczywistości z różnych LOD. Można tą relację oprzeć na zawartości kolumn dopisanych do związanych tabel z poszczególnych LoD’s. To daje jednak tylko relację 1:n. Teoretycznie to wystarcza… Ale w praktyce niekoniecznie klik

14 KONSTRUKCJA BAZY DANYCH - sposób „wiązań” między poziomami
Wariant bottom-up z użyciem dodatkowych tabel (relacja n:m) …Np. na DLM10 mamy segment drogi na wiadukcie nad inna drogą. (obiekt 2677 na drugim slajdzie) Po generalizacji w DLM250 ten wiadukt zapewne zostanie zlikwidowany do punktu, a droga, która na nim biegła rodzielona na dwa nowe segmenty. Konieczna będzie wtedy możliwość zapisu relacji m:n. Daje to tylko opcja dodatkowych tabel z linkami. Opcja kolumn jest bardziej wydajna. Do uzyskania odpowiedzi o obiekty z DLM10 związne z obiektem DLM250 potrzebne jest tylko jedno zapytanie do bazy. W opcji tabel dodatkowych trzeba zadać dwa pytania. Ma to znaczenie w przypadku stawiania serwisów WMS. W przypadku tego Sytemu to chyba jednak nie ma znaczenia? Wg mnie, jeżeli rozważamy linkowanie tylko dwóch LOD poprzez tabele dodatkowe, to wariant bottom-up i top-down są tożsame.

15 PROCES AKTUALIZACJI Proces aktualizacji DLM10 może pozostać oparty o model zaprojektowany dla TBD. Jednym z istotnych elementów procesu jest zarządzanie identyfikatorami obiektów. W przypadku dużych zmian poczynionych przez wykonawcę, aktualizacja powiązań będzie wymagała ingerencji operatora Należy rozważyć nałożenie na wykonawcę obowiązku aktualizacji informacji o wiązaniach między poziomami Proces aktualizacji oparty o dotychczasowy model nie pozwoli na szybką propagację zmian do baz DLM250 Proces aktualizacji DLM10 (zapewne) pozostanie oparty o model zaprojektowany dla TBD. Aktualizacja odbywać się będzie poprzez wydanie zewnętrznemu wykonawcy porcji danych BDG z zadanego obszaru. Dane sa „wycinane” ze spójnej całości, jaką stanowią w zasobie centalnym, przerabiane i ponownie integrowane. Jednym z istotnych elementów procesu jest zarządzanie identyfikatorami obiektów. Jeżeli BDG będzie MRDB dojdzie też konieczność aktualizacji tabel zawierających linki między obiektami z poszczególnych LOD. W przypadku dużych zmian poczynionych przez wykonawcę, aktualizacja tabel linkujących będzie wymagała ingerencji operatora. Niezbędne będzie porównywanie zasobu, który wrócił z aktualizacji z danymi z LOD pochodnego dla tego obszaru. Będzie to nowym elementem System Kontroli Danych. Pytanie brzmi: Czy jesteśmy w stanie ocenić nakład pracy związany z tym działaniem? Być może to działanie powinien zrealizować wykonawca aktualizacji. Może należy rozważyć, że w ramach aktualizacji DLM10 lepiej jest wydawać wykonawcy do przetworzenia wycinek danych podstawowych razem z wycinkiem danych z DLM250 (LOD pochodnego)? Wykonawca miałby (nowy) obowiązek wykonania w ramach aktualizacji fragmentu DLM10 propagacji zmian na DLM250 dla tego obszaru… Trzebaby wykonać analizę zysk/koszt dla takiego rozwiązania. Jednym z atutów MRDB jest łatwość propagowania zmian z podstawowego LOD na LOD pochodne. W teorii wygląda to łatwo. Informacja o edycji obiektu z bazy DLM10 jest rejestrowana i w konsekwencji wymusza dokonanie zmian na obiektach z nim powiązanych w DLM250. Możnaby mieć nadzieję, że ten mechanizm zadziała w SZBDG, że po każdorazowej aktualizacji danych DLM10 odpowiednie zmiany zostaną uwzględnione w DLM250. Jeżeli procesem generowania DLM250 z danych DLM10 będzie się zajmować podmiot zewnętrzny ten atut zniknie. Konstrukcja procesu jest taka: Wykonawca otrzymuje porcję danych DLM10 dla jakiegoś obszaru, aplikację „System generowania DLM250” i z tego ma zrobić dla zadanego obszaru DLM250. Odbywa się to co jakiś czas. Ten CZAS powinien być krótki, jednak nie wydaje się to możliwe. W takim trybie pracy szybkie propagowanie zmian na pewno się nie uda.

16 Niezbędne jest precyzyjne zdefiniowanie reguł generalizacji
PROCES GENERALIZACJI Organizacja procesu generalizacji będzie miała podobny model jak wypracowany dla aktualizacji DLM10 Niezbędne jest precyzyjne zdefiniowanie reguł generalizacji Jeżeli do budowy Systemu zostanie użyta baza obiektowo-relacyjna, to algorytmy generalizacji można zaimplementować jako metody manipulowania przypisane obiektom Weryfikacja efektów generalizacji – nowy element systemu kontroli danych Generalizacja danych DLM10 do DLM250, to min. temat organizacji procesu. Podobnie, jak w przypadku aktualizacji danych, największym wyzwaniem może okazać się konieczność wydawania porcji danych na zewnątrz, oraz integracji danych po przyjęciu ich od wykonawcy. Niezależnie od tego, czy generalizacja będzie realizowana w tej formie, czy bezpośrednio na bazie centralnej istotnym problemem będzie określenie reguł generalizacji. Do tego dochodzi pytanie: Jak te reguły zapisać? Czy będzie to norma, na której będzie opierał się wykonawca realizując autorski algorytm, czy takie algorytmy będą sformułowane precyzyjnie? A może warto rozważyć w tym miejscu zalety bazy obiektowo-relacyjnej, gdzie wiele funkcji związanych z generalizacją można wpisać w definicje obiektów? (Chwila o bazie obiektowo relacyjnej) Podejmowane w Europie badania wykazują, że adaptując podstawy modelu obiektowo-relacyjnego można znacząco zwiększyć możliwości systemu. Baza, o której z naciskiem mówię, że jest obiektowo-relacyjną ma kilka cech, nad którymi warto się pochylić. Element rzeczywistości jest reprezentowany przez obiekt, który można elastycznie zaprojektować. Dzięki temu: - Możemy zapisać wiele reprezentacji geometrii - Oczywiście ma atrybuty opisowe - Ma przypisane metody manipulowania – to tutaj można wstawić funkcje realizujące niektóre algorytmy generalizacji

17 ZŁOŻONOŚĆ ZASOBU DANYCH
Konieczność wdrożenia złożonego modułu metadanych System zarządzania z użyciem metadanych powinien wspomagać podejmowanie decyzji - raportowanie stanu istniejącego (braki w danych, zróżnicowanie jakości) - zarządzanie etapami pozyskiwania danych - zarządzanie planami aktualizacji - raportowanie stanu procesu generowania DLM250 Opracowując model wielorozdzielczych i wieloreprezentacyjnych baz danych należy zwrócić szczególną uwagę na zapewnienie odpowiedniej struktury dla metadanych. Prawidłowe wykorzystanie tych baz danych nie jest możliwe bez dostępu do informacji na temat dokładności i szczegółowości danych w poszczególnych fragmentach przestrzeni. Odpowiednia informacja o znaczeniu pojęciowym danej reprezentacji geometrycznej może być istotna zarówno dla użytkowników w procesach ekstrakcji wybranych informacji z bazy danych, w procesach analiz przestrzennych jak i w procesie produkcji map z bazy danych. Wśród typowych atrybutów o charakterze metadanych można wymienić: sposób reprezentacji geometrycznej obiektu, dokładność danych, źródło danych, ale również w taki sposób można traktować numer LoD przypisany do obiektu. Metadane musza być dodawane dla każdego procesu aktualizacyjnego (delete, insert, update). Na podstawie meteadanych system zarządzania wykonuje musi wspomagać wydawanie decyzji. Powinno to działać tak, jak scheduler – tzn. w odpowiednich interwałach czasowych uruchamiany jest wskazówka (polecenie). Może ona informować: o konieczności update'u warstwy niższej (bo przedawnił się stan aktualności danych, bo minął czas przewidziany na wykonanie nowego obszaru, bo w warstwach podstawowych wprowadzono zmiany na obiektach, które sa powiązane z warstwami dodatkowymi (dwujezdniówki)), O konieczności update’tu warstwy wyższej (bo przedawnia się stan aktualności danych, bo minął czas przewidziany na wykonanie nowego obszaru, oraz jeśli z metadanych wynika, że znaleziono na niższej błąd wynikający z generalizacji),

18 NAJWIĘKSZE WYZWANIA PROJEKTU SZWBT w POLSCE
Procesy produkcji wykonywane przez firmy komercyjne Dane pozyskiwane etapowo, w niejednolity sposób („obszarowo” i „warstwowo”) Brak koncepcji aktualizacji i jednoznacznego powiązania z systemami „wielkoskalowymi”.