Główny Geodeta Kraju, szybko i konkretnie odpowiedział na pytania, zadane kilka dni temu, przez stowarzyszenie Geodeci dla RP. Większość z pytań, które dotarły do Stowarzyszenia, związana była z doświadczeniami (między innymi moimi), z trwających 8 lat prób wymieniania informacji w formacie GML. Odpowiedzi, będą miały znaczący wpływ na sposób funkcjonowania procedur MicroGeoCad’a. Poniżej, znajdziecie Państwo pytania, które zostały zadane, odpowiedzi Głównego Geodety Kraju oraz moje (tradycyjnie lekko złośliwe) komentarze.
Oceniając wartość odpowiedzi GGK, proszę wziąć pod uwagę to, że odpowiedź zależy od … terminu, w którym odpowiedź była udzielana. Inna była na wiosnę a inna jesienią 🙁 A oto szczegóły…
Pytanie 1: Czy istnieją przepisy, regulujące nazewnictwo plików służących do wymiany informacji?
Odpowiedź: Oficjalna nazwa plików do wymiany informacji brzmi „pliki służące do aktualizacji odpowiednich baz
danych” (§ 35 ust. 5 wprowadzenie do wyliczenia rozporządzenia ws. standardów), natomiast wymienione różne nazwy potoczne nie powinny mieć wpływu na zrozumienie zagadnienia aktualizacji baz danych. Natomiast sam sposób nadawania nazw plikom jest szczegółowo opisany w § 35 ust. 5 rozporządzenia ws. standardów.
Komentarz: Oficjalną nazwę plików do wymiany informacji wszyscy znamy, ale jest wykorzystywana tylko w Głównym Urzędzie Geodezji i Kartografii i na zajęciach na uczelni. Nie wyobrażam sobie, żeby w ktoś używał jej w praktyce produkcyjnej. Wspomniany w odpowiedzi § 35 ust. 5, jest właśnie źródłem problemów. Po pierwsze nie uwzględnia on „kierunku” wymiany informacji, przez co trudno się porozumieć („… nie wiem, czy teraz mówi Pan o pliku, który dostałem od Was, czy pliku, który mam Wam oddać …„), po drugie bywa przyczyną utraty danych ( … szlag … nadpisałem sobie plik, który dostałem z Ośrodka, plikiem, który miałem wysłać …), i po trzecie nie wszyscy go stosują ( dodając np. słowa „Dane” albo „Blokada” i wymagając umieszczania tych słów w plikach „wracających” do Ośrodka).
Rozwiązanie problemu: Wystarczyło by: a) napisać, że Ośrodek wydaje plik „do aktualizacji„, a wykonawca pracy zwraca plik „zaktualizowany„, b) dodać do nazwy pliku trzeci człon, który informował by o „kierunku przepływu informacji”, np. poprzez dodanie do pliku przygotowywanego przez wykonawcę, słowa „różnicowy” czy też „aktualny” i c) zobligować Ośrodki (czyli autorów programów, stosowanych w Ośrodkach) do stosowania się do tych zapisów.
Pytanie 2: Czy Ośrodek może żądać od wykonawcy oddawania pliku o takiej samej nazwie
i rozszerzeniu, jak plik, który wydał?
Odpowiedź: Sprawa nazewnictwa uregulowana jest szczegółowo w § 35 ust. 5 rozporządzenia ws. standardów.
Komentarz: Pozwolę się nie zgodzić z tą odpowiedzią – sprawa nie jest w pełni uregulowana. Ośrodki – zwłaszcza te, które blokują bazę – wymagają oddawania plików o tej samej nazwie, co plik, który wydały. Przynajmniej kilkanaście razy pomagałem naprawić błędy spowodowane nadpisaniem pliku „z ośrodka” plikiem przygotowywanym „do ośrodka”.
Rozwiązanie: Rozwiązanie, zaproponowane do pytania numer 1, rozwiązuje również ten problem.
Pytanie 3: Czy istnieją precyzyjne i szczegółowe wytyczne techniczne, dotyczące plików, służących do
wymiany informacji pomiędzy Ośrodkami a wykonawcami prac geodezyjnych?
Odpowiedź: Struktura plików GML dla poszczególnych baz danych wynika wprost z przepisów odpowiednich
rozporządzeń. Natomiast wszystkie schematy xsd służące do walidacji poprawności plików GML są
dostępne na stronie BIP GUGiK i sukcesywnie publikowane w repozytorium interoperacyjności.
Komentarz: Irytująca odpowiedź! Oczywiście, że struktura plików gml „wynika wprost z przepisów”, tyle, że te przepisy są niewystarczające. Gdyby były, to wszystkie Ośrodki miały by te same wymagania co do struktury plików. Dopiero wspomniane przepisy uzupełnione odpowiedziami na pytania 11 – 16, zaczynają „nadawać się do użytku”.
Rozwiązanie: Opublikowanie szczegółowych wytycznych lub uzupełnienie istniejących przepisów, treścią odpowiedzi na pytania 11-16, udzielone Stowarzyszeniu, przez Głównego Geodetę Kraju.
Pytanie 4: Czy Ośrodek może wydać plik, który nie przechodzi walidacji – a jeżeli tak, to czy w takim
przypadku może żądać oddania przez wykonawcę pliku poprawnego?
Odpowiedź: Jeśli organ wydaje plik GML, to plik powinien być poprawny. Jeśli są takie sytuacje, to prosimy
o przekazanie przykładów, abyśmy mogli podjąć odpowiednie działania.
Komentarz: Ostatnio zdarzyło się, że wykonawca otrzymał z Ośrodka, trzy poprawne gml’e pod rząd, więc jest wyraźny postęp. Oczywiście będziemy od teraz wysyłać takie pliki do Głównego Urzędu Geodezji i Kartografii. Czytając odpowiedź, można odnieść wrażenie, że osoba, która ją przygotowała, nie zdaje sobie sprawy z tego, jaki śmietnik jest wydawany w GML’ach i jakie są z nimi problemy. Zapraszam na moją stronę z uwagami.
Rozwiązanie: Po pierwsze: walidator (czas na to najwyższy – mija właśnie 9 lat od wprowadzenia standardu GML), po drugie: weryfikacja funkcjonalności programów wykorzystywanych przez Ośrodki, ponieważ niektóre programy nie mają funkcji poszukiwania obiektów na podstawie identyfikatora lokalnego (lub obsługa nie potrafi takiej funkcji odnaleźć) i rozmawiając o błędach, trzeba stosować metodę opisową „… ta zasuwa na północ od szamba…” i po trzecie: to nie jest odpowiedź na pytanie!
Pytanie 5: Czy planowane jest przygotowanie programu umożliwiającego walidację plików w formacie
GML wydawanych przez Ośrodek oraz zwracanych przez wykonawcę?
Odpowiedź: Tak, planowane jest przygotowanie programu do walidacji plików w formacie GML.
Komentarz: Słyszymy to od 9 lat! Czas się wziąć do pracy i napisać lub zlecić napisanie odpowiedniego programu. Standardowe walidatory xml’owe, nie do końca się sprawdzają w przypadku gml’i, więc potrzebny jest walidator dostosowany do specyfiki gml’a.
Rozwiązanie: Grudzień 2021 – na stronach GUGiK’u pojawiła się właśnie informacja o konkursie na walidator. Maj 2022 – zastępczyni odwołanego GGK, odwołała właśnie konkurs na walidator. Do czasu odwołania zastępczyni, konkursu nie będzie i walidatora pewnie też. Październik 2022 – w sprawie walidatora cisza, a do stycznia coraz bliżej 🙁
Pytanie 6: Czy Ośrodek może żądać usunięcia z pliku GML wskazanego obiektu lub obiektów?
Odpowiedź: Nie jest możliwe udzielenie wiążącej odpowiedzi na tak postawione pytanie. Prosimy o przedstawienie
szczegółów sprawy.
Komentarz: Inspektor, który odbierał plik GML, zażądał usunięcia obiektu, ponieważ pomiędzy wygenerowaniem pliku dla wykonawcy, a momentem oddania pliku, obiekt ten został zaktualizowany w bazie, przez innego wykonawcę. Jeżeli sytuacja się powtórzy, to szczegóły zostaną przesłane do Urzędu.
Rozwiązanie: Programy, które stosowane są w Ośrodkach, powinny mieć możliwość, zasilania baz danych obiektami, wyselekcjonowanymi z pliku GML lub korzystać z informacji o cyklu życia obiektu do automatycznego selekcjonowania obiektów.
Pytanie 7: Czy Ośrodek może żądać aktualizacji pliku np. w ciągu 48 godzin?
Odpowiedź: Nie. Przepisy prawa nie przewidują możliwości stawiania takich żądań.
Komentarz: Niestety takie sytuacje się zdarzają. Użytkownik MGC, otrzymał w rozmowie telefonicznej, następującą uwagę: „… musi Pan oddać GML’a na poniedziałek (2 dni robocze – przyp. red.), bo zablokowaliśmy spory kawałek bazy, a inni też chcą pracować na tym terenie. Jak by Pan używał formatu KCD, to by nie było problemu. GML się do niczego nie nadaje – niech Pan tego nie używa.„
Rozwiązanie: Teraz można się będzie powołać na odpowiedź Głównego Geodety.
Pytanie 8: Czy Ośrodek może nie przyjąć pliku GML uzasadniając to jedynie stwierdzeniem „plik jest
błędny”?
Odpowiedź: Samo stwierdzenie, że plik jest błędny jest niewystarczające i w miarę możliwości powinny być również
podane szczegóły dotyczące zidentyfikowanego błędu.
Komentarz: Niestety bardzo rzadko zdarza się, aby Ośrodek udzielił konkretnej odpowiedzi. Nie wynika to ze złej woli osoby weryfikującej plik, a z niedostatków funkcjonalności programu, z którego korzysta. Jeżeli już pojawia się komunikat o przyczynach błędu, to trudno go zrozumieć, a w związku z tym trudno błąd naprawić. Źródłem problemu jest również brak walidatora oraz nieprecyzyjne zapisy „standardów”.
Rozwiązanie: Walidator + uszczegółowienie „standardów”
Pytanie 9: Pytanie dotyczyło pola powierzchni klasoużytku po podzieleniu działki, ale informacja, która do mnie dotarła nie pozwalała na zadanie bardziej szczegółowego pytania. Jeżeli uda mi się pozyskać szczegółowe informacje, to będę drążył temat.
Pytanie 10: Czy obiekty mogą zawierać łuki kołowe?
Odpowiedź: Nie.
Komentarz: Proste pytanie i jasna odpowiedź! Szkoda, że zasada ta nie jest respektowana. Brak też uzasadnienia dla takiego podejścia – instrumenty pomiarowe, matematyka, bazy danych oraz grafika komputerowa, radzą sobie z takimi składnikami obiektów. Ale najważniejsze, że sprawa jest teraz jasna, a więc: Panie Wojtku – sprawa skarp jest już jasna, Pani Magdo – nadal nie wiem co Pani doradzić w sprawie błędów topologii, ale teraz rozumie Pani moje stanowisko, Pani Katarzyno – przypominam naszą rozmowę dotyczącą kilkudziesięciu budynków, z bazy EGiB, Panie Macieju – pamięta Pan nasz zakład dotyczący krawężników? Wygrałem 🙂
Rozwiązanie: Teraz już nic nie poradzimy – trzeba systematycznie czyścić bazy z łuków kołowych, a na przyszłość: starannie przygotowywać przepisy i na czas publikować precyzyjne, jasne wytyczne. Trudno też zrozumieć po dla ogrodzeń, bram i furtek zastosowano geometrię „MultiCurve”.
Pytanie 11: Czy w pliku oddawanym do Ośrodka mają się również znaleźć dane obiektów, które nie były modyfikowane przez wykonawcę?
Odpowiedź: Tak. Jest to konieczne dla zachowania poprawności przekazywanych plików GML, kompletności ich
treści i możliwości dokonania automatycznej kontroli.
Komentarz: Skoro identyfikator lokalny jednoznacznie identyfikuje obiekt, a te same dane są w bazie, to wydaje się to zbędne. Jedna z aplikacji stosowanych w Ośrodkach, nie wymaga oddawania obiektów, które nie były modyfikowane, inna traktuje brak takich obiektów jako dowód ich usunięcia. Powodem bałaganu był brak precyzyjnych wytycznych. W odpowiedzi brak wskazania odpowiednich przepisów, ale ważne, że odpowiedź jest.
Rozwiązanie: Odpowiedź Głównego Geodety, rozwiązuje problem.
Pytanie 12: Czy obiekty, które zostały zmodyfikowane, muszą być zapisane w dwóch blokach „featureMember”, z których pierwszy zawiera dane oryginalne, a drugi aktualne?
Odpowiedź: Obiekty modyfikowane zawierają wersję oryginalną obiektu z dopisanym przez wykonawcę atrybutem
koniecWersjaObiekt oraz nową instancję tego obiektu z nową wartością atrybutu startWersjaObiekt oraz nowymi wartościami zmodyfikowanych atrybutów. W związku z powyższym występowanie atrybutu koniecWersjaObiekt w koincydencji z brakiem atrybutu koniecObiekt (porównaj z odpowiedzią na pytanie 13) świadczy o modyfikacji obiektu i w pliku GML powinna się znaleźć nowa instancja tego obiektu, która co do zasady powinna zostać wprowadzona do bazy danych w miejsce wersji dotychczasowej z datą faktycznie dokonanej aktualizacji bazy danych ośrodka.
Komentarz: Jedna z aplikacji stosowanych w Ośrodkach, komunikuje w takiej sytuacji błąd duplikatu identyfikatora lokalnego.
Rozwiązanie: Odpowiedź Głównego Geodety, będzie argumentem w walce o przyjecie pliku.
Pytanie 13: Czy obiekty, które zostały usunięte, muszą być zapisane w dwóch blokach „featureMember”, z których pierwszy zawiera dane oryginalne a drugi aktualne, lub powinny być zapisane w jednym bloku ale z ustawioną wartością atrybutu „koniecObiektu”, a może w ogóle powinny być pominięte podczas generowania pliku dla Ośrodka?
Odpowiedź: Nie. Aby zasygnalizować usunięcie obiektu należy dodać do obiektu wartość atrybutu koniecWersjaObiekt oraz koniecObiekt, co powinno być interpretowane przez system powiatowy jako usunięcie obiektu. Natomiast ostateczne wartość wymienionych atrybutów nadaje ośrodek w momencie aktualizacji bazy danych zasobu, wpisując w tych atrybutach datę i czas faktycznego usunięcia obiektu z bazy. Natomiast w przypadku kiedy takiego obiektu nie ma już bazie, to rekord w pliku wykonawcy nie wywołuje żadnych skutków, ponieważ brak obiektu świadczy, że został on usunięty w ramach innej pracy, która została przyjęta wcześniej.
Komentarz: Sprawa jest (teraz) jasna, choć trochę brak tu logiki – z odpowiedzi wynika, że „nieistnienie obiektu” jest jego „nową wersją”, ale niech będzie 🙂
Rozwiązanie: Odpowiedź Głównego Geodety, rozwiązuje problem.
Pytanie 14: Czy nowe obiekty mają mieć podaną przestrzeń nazw? Jeżeli tak, to jakie są zasady jej tworzenia? Czy wystarczy, że co do formy będzie zgodna z odpowiednimi przepisami, natomiast treść, podobnie jak identyfikator lokalny – będzie sprawą oprogramowania wykonawcy?
Odpowiedź: Tak. Zgodnie z § 35 ust. 5 pkt 2 rozporządzenia ws. standardów, dane do aktualizacji baz danych zasobu sporządza się w postaci plików w formacie GML, w których obiekty nowe otrzymują identyfikatory nadane przez wykonawcę, wyróżniające te obiekty w pliku GML. Przestrzeń nazw natomiast jest składnikiem obligatoryjnym identyfikatora IIP, a jej wartość wynika z ewidencji zbiorów i usług danych przestrzennych w powiązaniu z przepisami odpowiednich rozporządzeń (EGiB, GESUT, BDOT500).
Komentarz: Pytanie pojawiło się po zarzutach, że w przypadku obiektów nowych, przestrzeń nazw, nie może zawierać ciągu znaków „PZGiK”, a po zmianie na „ABCDE”, że musi zawierać „PZGiK”. Teraz sprawa jest jasna.
Rozwiązanie: Odpowiedź Głównego Geodety, rozwiązuje problem.
Pytanie 15: kto odpowiada za atrybut „poczatekWersji” i kto go powinien ustawić?
Odpowiedź: W obecnych przepisach nie ma atrybutu „poczatekWersji”. Proszę o doprecyzowanie pytania.
Komentarz: Chodziło oczywiście o atrybut „PoczatekWersjiObiektu”, a sprawa wiąże się z uwagą jednego z inspektorów, który powiedział, że „… to nie jest błąd, ale z tego co wiem, atrybut ten w przypadku obiektów nowych, nie powinien być ustawiany przez oprogramowanie wykonawcy, tylko oprogramowanie Ośrodka …„. Moim zdaniem, atrybut ten – podobnie jak „startObiekt” – powinien być ustawiony przez soft wykonawcy, a jeżeli oprogramowanie Ośrodka „chce”, to może te wartości zmodyfikować w momencie przyjęcia do zasobu.
Rozwiązanie: Sprawa nie jest pilna ale pewnie jeszcze wrócę do tego tematu.
Pytanie 16: Czy w bloku informacji o obiekcie „A”, powinny znaleźć się relacje do usuniętego obiektu „B”?
Odpowiedź: Co do zasady takie relacje powinny zostać usunięte. Tym samym obiekt A powinien mieć nową wersję,
o ile istnienie tego obiektu bez relacji jest uzasadnione (np. istnienie schodów bez budynku).
Komentarz: Właśnie o to chodziło! Gdyby taki zapis został opublikowany 10 lat temu, np. w „standardach”, to uniknęlibyśmy wielu nieporozumień.
Rozwiązanie: Odpowiedź Głównego Geodety, rozwiewa wątpliwości.