|
|2023-06-19|
Geodezja, Prawo, CIEKAWE TEMATY
Aktualizacja danych PZGiK z wykorzystaniem formatu 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 w zasobie trzeba zaktualizować na podstawie danych przekazanych przez wykonawcę pracy geodezyjnej i to w sposób jak najbardziej zautomatyzowany, tzn. pozbawiony ingerencji operatorów.
Autor: WALDEMAR IZDEBSKI
Obecnie – na podstawie rozporządzenia Ministra Rozwoju z 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ówPowyż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 obiekt w pliku GML uzyskanym z PODGiK, będący składnikiem jednej z powiatowych baz danych ( EGiB, GESUT, BDOT500), ma: 1. Identyfikator Infrastruktury Informacji Przestrzennej (IdIIP) zawierający następujące składniki: • przestrzenNazw np. PL.PZGiK.6310.GESUT
• lokalnyId np. 82095AE9-6CD9-4752-BEED-004DB89D5399
• 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: • startObiekt np. 2023-05-08T11:57:50
• startWersjaObiekt np. 2023-05-08T11:57:50
• koniecWersjaObiekt np. 2023-05-08T12:57:50
• 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 – 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”. GeoMapGML 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 oparciu o te same zasady. Sprawdzenie 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. Kiedy obiektu nie ma w otrzymanym pliku danych, a w terenie zostaje stwierdzone jego istnienie, wykonawca 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 wprowadzeniem nowego obiektu do bazy danych i nadaniem 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, 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.
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, prof. PW, były GGK
| 
