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:
- https://geomapmaker.online/geoserver/UniejowMwMpzp/wfs?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=UniejowMwMpzp:aktplanowaniaprzestrzennego218590
- https://geomapmaker.online/geoserver/UniejowMwMpzp/wfs?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=UniejowMwMpzp:aktplanowaniaprzestrzennego218590,UniejowMwMpzp:dokumentformalny218590,UniejowMwMpzp:rysunekaktuplanowaniaprzestrzennego218590
(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
7. Spójrzmy teraz na zawartość pliku z zapisaną odpowiedzią z pkt. 4:
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.
