Aktualizacja PZGiK z wykorzystaniem GML

    Od roku 1998, kiedy pierwszy raz pisałem o automatyzacji procesu aktualizacji danych   (Izdebski 1998), wiele się zmieniło technologicznie, ale zasady pozostały identyczne, tzn. dane z zasobie trzeba zaktualizować na podstawie danych przekazanych  przez wykonawcę pracy geodezyjnej i to w sposób jak najbardziej zautomatyzowany, tzn. pozbawiony ingerencji operatorów.

    Obecnie na podstawie Rozporządzenia Ministra Rozwoju z dnia 18 sierpnia 2020 r. w sprawie standardów technicznych wykonywania geodezyjnych pomiarów sytuacyjnych i wysokościowych oraz opracowywania i przekazywania wyników tych pomiarów do państwowego zasobu geodezyjnego i kartograficznego, aktualizacji danych PZGiK dokonuje się z wykorzystaniem formatu GML:

Rys. 1 Fragment rozporządzenia ws. standardów

 

    Powyższa zasada oznacza, że w obiektach otrzymanych z PODGiK w pliku GML, wykonawca wprowadza zmiany przez utworzenie nowych wersji tych obiektów, przy jednoczesnym zachowaniu ich dotychczasowych identyfikatorów. Zachowanie identyfikatorów jest konieczne, ponieważ na ich podstawie oraz na podstawie utworzonych przez wykonawcę nowych wersji obiektów, będą podczas przyjmowania GML do zasobu dokonywane odpowiednie zmiany w bazach PODGiK.

    W przypadku nowych obiektów sprawa jest prostsza, ponieważ nie znajdowały się one w wydanym pliku GML i wykonawca zwyczajnie dodaje takie obiekty do pliku GML z nowymi identyfikatorami, zapewniającymi unikalność w obrębie pliku. Identyfikatory te mają jedynie charakter roboczy, bo przy przyjmowaniu do zasobu, nowe obiekty uzyskują i tak nowe identyfikatory nadawane przez system wykorzystywany do prowadzenia zasobu.

1. Identyfikator i cykl życia obiektu

   W związku z obowiązującymi przepisami, każdy obiekty w pliku GML uzyskanym z PODGiK,  będący składnikiem jednej z powiatowych baz danych (EGiB, GESUT, BDOT500) posiada:

1. identyfikator Infrastruktury Informacji Przestrzennej (IdIIP), zawierający składniki:
1. przestrzenNazw np. PL.PZGiK.6310.GESUT
   
2. lokalnyId np. 82095AE9-6CD9-4752-BEED-004DB89D5399
   
3. wersjaId np. 2023-05-08T11:57:50
   
2. informacje o cyklu życia obiektu, w postaci czterech atrybutów, które są wypełnione adekwatnie do  stanu obiektu danego obiektu, czyli czy jest to obiekt istniejący czy archiwalny:
1. startObiekt np. 2023-05-08T11:57:50
   
2. startWersjaObiekt np. 2023-05-08T11:57:50
3. koniecWersjaObiekt np. 2023-05-08T12:57:50
4. koniecObiekt np. 2023-05-08T12:57:50

   Składnik identyfikatora obiektu, jakim jest przestrzenNazw, wynika z identyfikatora zbioru, pod jakim funkcjonuje on w Ewidencji Zbiorów i Usług Informacji Przestrzennej prowadzonej przez Głównego Geodetę Kraju. Przykładowy identyfikator postaci: PL.PZGiK.6310.GESUT oznacza zbiór zarejestrowany pod numerem 6310, w którym są dane GESUT powiatu węgrowskiego. Składnik lokalnyId jest unikalnym identyfikatorem obiektu w danej przestrzeni nazw, a składnik  wersjaId jest identyfikatorem kolejnej wersji tego obiektu. 

   Wszystkie atrybuty dotyczące "cyklu życia" obiektu mają postać tzw. "stempla czasu" w postaci daty i czasu, które rozdzielone są literą "T" np. 2023-05-08T12:57:50.

    Wymienione powyżej atrybuty wykorzystywane są do aktualizacji powiatowych baz danych PZGiK  na podstawie plików GML, przekazywanych przez wykonawców prac geodezyjnych. Będzie o tym szerzej w dalszej części artykułu.

   Dopełnieniem wymienionych wyżej atrybutów systemowych, są atrybuty związane z klasą (kategorią)  konkretnego obiektu, w tym bardzo istotny atrybut dotyczący jego geometrii. Przykład zapisu kompletnego obiektu, pochodzącego z bazy GESUT, przedstawiono na rys. 2.

Rys. 2 Przykład zapisu obiektu GESUT w formacie GML

2. Praktyczna realizacja aktualizacji

   Tak więc wykonawca pracy geodezyjnej otrzymuje wydany z PODGiK plik GML, w którym znajdują się obiekty związane z obszarem zgłoszonej pracy geodezyjnej. 

    Poniżej przykład takich danych odczytanych w programie GeoMapGML, które można pobrać ze strony www.geo-system.com.pl w sekcji Download, i który do celów niekomercyjnych jest bezpłatny. Można w nim wczytać i przeglądać pliki GML z baz EGiB, GESUT i BDOT500, a w zastosowaniach komercyjnych można także takie dane zaktualizować i przygotować  plik bądź pliki GML, które zostaną wysłane do PODGiK. Oczywiście system, z którego wygenerowano GML, nie powinien mieć znaczenia dla tworzonego pliku GML, ponieważ aktualne rozporządzenia precyzyjnie określają model danych dla baz EGiB, GESUT i BDOT500 i wszystkie systemy wykorzystywane do prowadzenia zasobu w powiatach powinny pliki GML generować w o oparciu o te same zasady. Sprawdzenia poprawności plików GML można wykonać walidatorem opublikowanym przez GUGIK.

Rys. 3 Przykład danych wydanych dla pracy geodezyjnej

Każdy wydany obiekt posiada wypełniony atrybut IdIIP oraz atrybuty dotyczące "cyklu życia" tj.: startObiekt i startWersjaObiekt:

Rys. 4 Przykład zapisu atrybutów systemowych obiektu bazy BDOT500 zaznaczonego na rys. 3

   W procesie aktualizacji danych otrzymanych z PODGiK występują następujące sytuacje, które trzeba w tym procesie obsłużyć:

• dodanie nowego obiektu,
• usunięcie obiektu,
• modyfikacja obiektu.

2.1 Dodawanie nowego obiektu

   Dodanie nowego obiekty jest najprostszą czynnością w procesie aktualizacji danych. W sytuacji kiedy obiektu nie ma w otrzymanym pliku danych, a wykonawca stwierdza jego istnienie w terenie, to w takim przypadku dodaje obiekt do pliku GML z nowym identyfikatorem oraz atrybutami startObiekt, który z zasady jest tożsamy z atrybutem startWersjaObiekt.

   Przy przyjmowaniu do zasobu, nadany przez wykonawcę identyfikator obiektu zostanie zastąpiony w PODGiK, nowym identyfikatorem nadanym przez system służący do prowadzenia zasobu, a atrybuty startObiekt i startWersjaObiekt uzyskają wartości związane z datą i czasem dodawania tego obiektu do zasobu.
    Tak więc wartości tych atrybutów nadane przez wykonawcę mają jedynie charakter tymczasowy (techniczny), bo prawdziwy "cykl życia" obiektu w bazie danych zaczyna się od jego przyjęcia do zasobu. Podczas dodawania nowego obiektu do bazy zostaną ustawione także atrybuty związane z oznaczeniem operatu, na podstawie którego obiekt wchodzi do bazy PODGiK. 

  Uwaga:

Może się pojawić problem w sytuacji, kiedy obiekt zostanie pomierzony wcześniej przez innego wykonawcę. W takiej sytuacji, jeśli różnice w lokalizacji obiektu mieszczą się w dokładności pomiaru, to taki obiekt powinien być zignorowany i nie przyjmowany do zasobu. W sytuacji kiedy różnice są istotne, to PODGiK powinien wyjaśnić i zdecydować, który obiekt pozostaje w bazie.

2.2 Usunięcie obiektu

   Kolejną czynnością występującą w procesie aktualizacji danych jest usunięcie obiektu, co jest odzwierciedleniem sytuacji,  w której wykonawca stwierdza, że obiekt już nie istnieje w terenie.

Rys. 5 Ilustracja usunięcia obiektu, który był obiektem aktywnym na rys. 3

    W wyniku czynności usunięcia obiektu, przestajemy go widzieć w standardowej wizualizacji pliku wykonawcy, ale obiekt taki dalej istnieje, tyle tylko, że ma ustawiony atrybut koniecObiekt i standardowo oprogramowanie, w którym pracujemy go nie pokazuje, co przedstawiono na rys. 6.

Rys. 6 Ilustracja atrybutów cyklu życia dla obiektu usuniętego

    Przy przyjmowaniu do zasobu system wykorzystywany do prowadzenia zasobu musi odnaleźć taki obiekt w bazie danych i dokonać odpowiednich działań, które zamkną "cykl życia" tego obiektu w bazie danych. Atrybut koniecObiekt zostanie ustawiony na odpowiednie wartości daty i czasu jakie będą w chwili wykonania tej czynności w bazie danych, ponieważ to od tej chwili kończy się "cykl życia" obiektu w bazie danych, a wartość atrybutu koniecObiekt przekazana przez wykonawcę niosła jedynie informację, że taki obiekt trzeba usunąć w procesie aktualizacji.

  Uwaga:

Jeśli system nie odnajdzie  obiektu o określonym identyfikatorze, to oznacza, że obiekt został usunięty wcześniej i tej sytuacji informacja wykonawcy, o konieczności usunięcia obiektu, powinna zostać zignorowana, ponieważ obiekt jest już usunięty.

2.3 Modyfikacja obiektu

   Modyfikacja obiektu polega na zamknięciu jego wersji otrzymanej z PODGiK (rys. 7) i utworzeniu nowej wersji obiektu, która zawiera odpowiednie modyfikacje (rys. 8).

Rys. 7 Obiekt do modyfikacji

Rys. 8 Zamknięta wersja obiektu

Modyfikacja obiektu, powoduje zamknięcie poprzedniej wersji (rys. 7 i 8) i jednoczesne (w tym samym czasie) utworzenie nowej wersji (rys. 9).

Rys. 9 Zmodyfikowana wersja obiektu

    Przy przyjmowaniu do zasobu system służący do prowadzenia zasobu musi odnaleźć taki obiekt oraz jego wersję pierwotną jaka była wydana do pliku GML i dokonać jej zamknięcia, czyli ustawić atrybut koniecWersjaObiekt na chwilę aktualizacji.
  Następnie tworzona jest w bazie nowa wersja tego obiektu zgodna z wersją przekazaną przez wykonawcę, ale z nową wartością atrybutu startWersjaObiekt nadaną przez system do prowadzenia zasobu. Od tej chwili w bazie zaczyna funkcjonować nowa wersja obiektu, a poprzednia ma status wersji archiwalnej. Podczas tworzenia nowej wersji obiektu zostaną w niej ustawione także atrybuty związane z oznaczeniem operatu, na podstawie którego wersja wchodzi do bazy PODGiK.

  Uwaga:

Jeśli system nie odnajdzie  obiektu o określonym identyfikatorze i wersji, to oznacza, że wydany obiekt (jego wersja) została w od chwili wydania zmieniona w PODGiK i w tej sytuacji wykonawca powinien pobrać tą najnowszą wersję obiektu z PODGiK i dokonać jej aktualizacji zgodnie ze swoimi pomiarami. Oczywiście wydłuża to realizację pracy geodezyjnej, ale niestety zgodnie z obowiązującymi przepisami nie ma innej możliwości wprowadzenia takich zmian.

3. Podsumowanie

   Cały opisany proces aktualizacji danych zawartych w powiatowych bazach danych można przedstawić schematycznie, tak jak pokazuje to rys. 10.

Rys. 10 Schemat aktualizacji baz danych z wykorzystaniem GML

    Innymi słowy obiekty zmodyfikowane przez wykonawcę muszą trafić do bazy danych prowadzonej w PODGiK. Wykrywanie zmian odbywa się na podstawie analizy identyfikatorów obiektów oraz cyklu ich życia jak opisano to powyżej, a ogólny schemat wykrywania zmian zarejestrowanych w plikach GML przedstawia rys. 11.

Rys. 11 Schemat wykrywania zmian w pliku GML

 

    Należy pamiętać, że stemple czasu wpisane przez wykonawcę, służą jedynie do sygnalizacji zmian, a właściwe zmiany odbywają w chwili modyfikacji rekordów w bazie PODGiK, czyli:

• Dodanie obiektu przez wykonawcę skutkuje wprowadzenie nowego obiektu do bazy danych i nadanie mu nowego identyfikatora IdIIP oraz atrybutów startObiekt i startWersjaObiekt, bo  w bazie PODGiK obiekty te będą funkcjonować dopiero od chwili ich przyjęcia do zasobu.
• Usunięcie obiektu przez wykonawcę skutkuje zakończeniem cyklu życia obiektu, który wykonawca wskazał do usunięcia. W efekcie skutkuje to ustawieniem w danym obiekcie atrybutu koniecObiekt, co czyni go obiektem archiwalnym.
  
• Modyfikacja obiektu przez wykonawcę skutkuje zakończeniem wersji obiektu funkcjonującej w PODGiK. Ponieważ wykonawca zmodyfikował obiekt, więc w procesie aktualizacji w PODGiK tworzymy jego nową wersję, na podstawie obiektu zmodyfikowanego i przekazanego przez wykonawcę. W nowej wersji ustawiamy atrybut startWersjaObiekt  na czas zgodny z chwilą aktulizacją bazy i od tej chwili w PODGiK będzie funkcjonowała nowa wersja obiektu.
   
  

O potencjalnych problemach, jakie mogą wystąpić w procesie aktualizacji powiatowych baz danych, napisano w uwagach umieszczonych czerwonych ramkach.

4. Literatura

1. Izdebski 1998 Aktualizacja danych w systemie GEO-MAP, VIII Konferencja Naukowo Techniczna -Towarzystwa Informacji Przestrzennej, Warszawa 1998. 
2. OGC, Geography Markup Language
   

 

dr hab. inż. Waldemar Izdebski