środa, 19 października 2022

Problematyka udostępniania podpisanych zbiorów APP zgodnych ze schematem aplikacyjnym za pomocą usług WFS i ATOM

W nawiązaniu do licznych wniosków, jakie trafiają do jednostek samorządowych, w których zarzuca się nieprawidłowe wykonywanie obowiązku dot. udostępniania danych przestrzennych z tematu zagospodarowanie przestrzenne i jednocześnie wymienia przykłady gmin, które jakoby udostępniały takie dane "poprawnie", postanowiliśmy zweryfikować w praktyce te twierdzenia i przetestować jedną z usług wymienionych przez podmioty składające wnioski.

Korespondencja najczęściej wskazuje  8 adresów usług pobierania (WFS), które zostały przygotowane przez dostawcę komercyjnego, w tym np. dla gminy Uniejów - i to na jej przykładzie dokonamy sprawdzenia prawdziwości twierdzeń zawartych w korespondencji.

1. Adres usługi znajduje się w Ewidencji zbiorów i usług prowadzonej przez GUGiK na stronie:

2. W rubryce usługa pobierania dla zbioru danych dla miejscowych planów zagospodarowania znajduje się adres usługi WFS:

3. Wywołanie zapytania GetCapabilities dla powyższej usługi zwraca listę warstw/obiektów dostępnych za pomocą usługi:

UWAGA: Po publikacji niniejszego wpisu dostawca usługi dokonał w niej zmian, m.in. w zakresie nazewnictwa obiektów, dlatego poniższe wywołania (aktualne na dzień przygotowania wpisu) mogą zwracać już inne odpowiedzi. Niemniej jednak kluczowe nieprawidłowości nadal występują, a dane zwracane przez usługę w dalszym ciągu nie są zgodne z rozporządzeniem i schematem.

a) Jak można sprawdzić w odpowiedzi na liście FeatureTypeList znajdują się elementy o nazwach w postaci:
  • UniejowMwMpzp:aktplanowaniaprzestrzennego218590
  • UniejowMwMpzp:dokumentformalny218590
  • UniejowMwMpzp:rysunekaktuplanowaniaprzestrzennego218590
Już w tym momencie nasuwa się pytanie, skąd takie nazewnictwo, zupełnie niewynikające z zapisów rozporządzenia, które wyraźnie definiuje obiekty typu:
  • AktPlanowaniaPrzestrzennego
  • RysunekAktuPlanowaniaPrzestrzennego
  • DokumentFormalny
Kolejne wątpliwości co do zawartości i poprawności usługi biorą się z elementów DefaultCRS (układ współrzędnych) i WGS84BoundingBox (prostokąt ograniczający).
b) W pierwszym elemencie znajdują się wartości EPSG:3857 i EPSG:404000, czyli odpowiednio układy WGS 84/Pseudo-Mercator oraz niestandardowy/niezdefiniowany układ współrzędnych. Tymczasem rozporządzenie wprost wymienia dwa państwowe układy stosowane dla zbiorów APP:
Kody EPSG tych układów to 2176-2179 (kolejne strefy PL-2000) oraz 2180 (PL-1992) - jak widać sprawdzana usługa nie spełnia wymagań w tym zakresie, gdyż stosuje zupełnie inne układy.

c) W elemencie WGS84BoundingBox dla obiektów z dokumentem i rysunkiem zakres prostokąta ograniczającego jest zupełnie inny niż dla elementu AktPlanowaniaPrzestrzennego , a wpisane wartości to -1.0, -1.0, 0.0, 0.0. Ponieważ współrzędne te odnoszą się do układu WGS84 podane są w stopniach (długość i szerokość geograficzna) i jak łatwo sprawdzić w żaden sposób nie mogą odnosić się do obszaru gminy Uniejów.

4. Niemniej jednak, pomimo powyższych zastrzeżeń, zbadajmy poprawność danych zwracanych przez usługę w odpowiedzi na zapytanie GetFeature:
(pierwsze wywołanie dotyczy pojedynczego obiektu, utożsamianego z AktPlanowaniaPrzestrzennego; drugie - wszystkich obiektów wchodzących w skład APP tj. akt + dokument + rysunek)

Treść obu odpowiedzi zapisujemy na dysku (Zapisz stronę jako...) do pliku .xml.
5. Otwieramy stronę walidatora danych APP na stronie  https://aplikacje.gov.pl/app/gov_xml_validator,
następnie  wybieramy opcję zbiór danych APP i dodajemy plik zapisany w poprzednim kroku (operacje powtarzamy również dla drugiego pliku).

W obu przypadkach wyniki walidacji są nieprawidłowe!

Już w tym momencie twierdzenia ze korespondencji należy uznać za nieprawdziwe.

6. Przyjrzyjmy się bliżej treści raportu z walidatora:
  • brak wskazania na schematy aplikacyjne gml, wfs i przede wszystkim schemat app z rozporządzenia:
    https://www.gov.pl/static/zagospodarowanieprzestrzenne/schemas/app/1.0
  • brak deklaracji elementu wfs:FeatureCollection
  • kod układu współrzędnych spoza rejestru EPSG zdefiniowanego w rozporządzeniu
  • brak obiektu app:AktPlanowaniaPrzestrzennego
Ostatni z błędów jest najpoważniejszy i powoduje przerwanie dalszej walidacji przez walidator. Jak widać zastrzeżenia z punktu 3a) okazały się słuszne.

7.  Spójrzmy teraz na zawartość pliku z zapisaną odpowiedzią z pkt. 4:

Od razu widoczny jest brak obiektu  AktPlanowaniaPrzestrzennego , zamiast niego występuje nieprawidłowy aktplanowaniaprzestrzennegozbiórap_id_169235.
W pliku w ogóle nie występuje przestrzeń nazw app: ze schematu aplikacyjnego. W danych zwróconych przez usługę zastosowano zamiast tego przestrzeń  UniejowMwMpzp:.

8. Ponieważ brak prawidłowo nazwanego obiektu APP powoduje przerwanie walidacji, to walidator nie sprawdza już dalej poprawności elementów wewnętrznych. Jednak analizując treść pliku i zapisy rozporządzenia można dostrzec kolejne nieprawidłowości:
  • element złożony  idIIP, składający się z 3 elementów (przestrzenNazw, lokalnyId, wersjaId), który jest wymagany wg załącznika do rozporządzenia, w danych dla Uniejowa w ogóle nie występuje, a zamiast niego wpisane są jedynie elementy składowe, na innym poziomie struktury dokumentu XML:

  • brak jest wymaganych elementów typPlanu, poziomHierarchii, status, obowiazujeOd
  • podobnie jak w przypadku idIIP brak jest złożonego elementu mapaPodkladowa; występuje jedynie składowa referencja na innym poziomie struktury
  • brak jest wymaganego elementu o nazwie zasiegPrzestrzenny z geometrią zapisaną w jednym z układów państwowych, zamiast niego informacja o geometrii planu zapisana jest w elemencie o nazwie geom i w innym układzie:

  • brak elementów dokumentUchwalajacy i rysunek, które dla planów obowiązujących są wymagane i powinny wskazywać na odpowiednie obiekty typu DokumentFormalny i RysunekAktuPlanowaniaPrzestrzennego
  • w danych z Uniejowa występują za to elementy dodatkowe, których nie ma zdefiniowanych w żadnym miejscu w rozporządzeniu ani schemacie aplikacyjnym - są to walidowalny_i_podpisany_GML, walidowalny_i_podpisany_zbior_przed_2020, walidowalny_i_podpisany_zbior_calosc
Brak elementów dokumentUchwalajacy i rysunek (w obiekcie AktPlanowaniaPrzestrzennego) oraz elementu uchwala w DokumentFormalny i plan w RysunekAktuPlanowaniaPrzestrzennego powoduje, że obiekty nie mają między sobą żadnego powiązania logicznego, przez co ze struktury dokumentu nie wynika w żaden sposób, do którego planu przynależy dany rysunek lub uchwała.

Ilustrację takiego stanu przedstawiono poniżej:

9. W korespondencji często wskazuje się przykład podłączenia badanej usługi w programie QGIS jako "dowód" na jej poprawność. Oczywiście sam fakt podłączenia danych w jakimś programie nie świadczy w żaden sposób, że dane te są zgodne z odpowiednimi przepisami prawa i odpowiednim schematem aplikacyjnym. Wszystkie przedstawione wyżej błędy i zastrzeżenia obowiązują również i w tym przypadku:
  • nazwa i tytuł warstw WFS podłączonych z usługi w QGIS są niezgodne z rozporządzaniem 
  • usługa nie obsługuje obowiązujących państwowych układów współrzędnych
  • struktura, zakres i nazwy elementów (atrybutów) również są niezgodne, co opisano już w pkt. 6. i 7.
  • obiekty (akt, dokument i rysunek) wczytują się bez powiązania między sobą, a skarżący pomija całkowicie, że w tej sytuacji nie jest możliwe zapisanie kompletnego zbioru, a jedynie wyeksportowanie 3 oddzielnych plików dla każdego typu z osobna
Nie jest zatem zaskakujące, że żaden z 3 plików możliwych do wyeksportowania z QGIS nie przechodzi walidacji i wykazywane są podobne błędy jak w metodzie opisanej w pkt. 4. i 5.:

10. Dla porównania treść przykładowych danych APP dla planu udostępnionych na stronie ministerstwa https://www.gov.pl/web/zagospodarowanieprzestrzenne/przykladowe-dane oraz efekt ich wczytania do programu QGIS:


Jak można zauważyć nazwy obiektów i elementów, układ współrzędnych oraz sama struktura dokumentu GML jest zupełnie inna niż w danych zwracanych w usłudze z gminy Uniejów.

Na koniec pokażemy dlaczego usługa ATOM jest właściwa do udostępniania zbiorów APP, które spełniają wymagania rozporządzenia w zakresie podpisu, treści i zgodności ze schematem.

Przede wszystkim usługa ATOM daje bezpośredni dostęp do kompletnego,  podpisanego  przez organ zbioru danych APP, w którym wszystkie obiekty posiadają odpowiednie powiązania między sobą (zgodnego ze schematem), co nie jest możliwe w przypadku opisanej wcześniej usługi WFS. Daje ona dostęp oddzielnie do obiektów typu plan, oddzielnie dla rysunków i oddzielnie dla dokumentów. Ponadto w badanej usłudze w żadnym miejscu nie występuje element stanowiący podpis elektroniczny udostępnianego zbioru. Jeszcze raz twierdzenia zawarte w korespondencji okazują się niezgodne z prawdą.

Poniżej przypominamy jak samodzielnie sprawdzić poprawność danych udostępnianych w ramach usługi ATOM.

Opis korzystania z usługi ATOM w narzędziu GUGiK:
  • adres usługi ATOM dla zbiorów APP to https://mpzp.igeomap.pl/atom
  • adres ten należy wkleić w polu Feed URL i kliknąć Otwórz Feed
  • po dodaniu adresu usługi wyświetlona zostanie lista dostępnych gmin 
  • po wybraniu gminy (np. Kowale Oleckie) należy przyciskiem pobrać informacje o dostępnych paczkach danych
  • w kolejnym kroku należy kliknąć przycisk Pobierz plik, co spowoduje zapisanie pliku w formacie GML
  • pobrany na dysk plik można następnie zwalidować przy pomocy opcji zbiór danych APP w oficjalnym walidatorze APP udostępnionym na stronie rządowej https://aplikacje.gov.pl/app/gov_xml_validator/
Pobrany z usługi ATOM zbiór danych dla gminy Kowale Oleckie możemy także sprawdzić usługą do weryfikacji podpisu elektronicznego na stronie rządowej:
Należy wybrać zapisany w poprzednim kroku plik i po chwili zostanie wyświetlona informacja o tym, czy podpis jest ważny i poprawny oraz kto i kiedy podpisał zbiór APP.



Dodatkowo można porównać treść pliku pobranego z usługi ATOM ze zbiorem APP dostępnym na stronie z wykazem planów (np. https://kowaleoleckie.e-mapa.net/wykazplanow) - będzie ona identyczna co do bajta.

o
Etykiety: , , ,