piątek, 28 października 2022

Podpisywanie zbiorów APP

Zgodnie z obowiązującymi wymogami prawnymi samorządy do końca października powinny mieć utworzone zbiory APP dla obowiązujących MPZP i Studium.

Jednak poza samym udostępnieniem zbioru istotny jest jeszcze jeden element - otóż zgodnie z rozporządzeniem Ministra Rozwoju, Pracy i Technologii z dnia 26 października 2020 r. w sprawie zbiorów danych przestrzennych oraz metadanych w zakresie zagospodarowania przestrzennego zbiór musi być podpisany przez Wójta, Burmistrza lub Prezydenta Miasta:


W związku z tym przypominamy naszym użytkownikom, że taki zbiór musi zostać podpisany obecnie oraz musi być podpisywany po każdej aktualizacji zbioru, tj. najczęściej po wprowadzeniu nowego planu lub zmiany.

Przygotowaliśmy dla Państwa instrukcję, jak w kilku krokach podpisać i umieścić zbiór APP w systemie.
Dostępna jest do pobrania TUTAJ
 
Efektem końcowym powinno być ujawnienie podpisanych zbiorów m.in. na Wykazie MPZP:
  

środa, 26 października 2022

Seminarium z zakresu numeracji adresowej

26 października na platformie Zoom odbyło się spotkanie dla pracownic i pracowników urzędów miast i gmin, które poświęcone było wykorzystaniu systemu iMPA w realizacji zadań samorządu - w szczególności w zakresie prowadzenia numeracji adresowe nieruchomości (EMUIA).

W telekonferencji wzięło udział niemal 400 osób z całej Polski. W czasie całego spotkania uczestnicy zadali kilkaset pytań, na które na bieżąco staraliśmy się odpowiadać. Pojawiło się również wiele podziękowań i głosów o przydatności tego typu telekonferencji.


Dziękujemy wszystkim za liczny udział i aktywne uczestnictwo!

Dla uczestników dostępne jest już nagranie całego spotkania*.
UPDATE: Do materiałów dodano również plik z listą pytań i odpowiedzi oraz slajdy z prezentacji.
*Na stronie należy wpisać dane podane przy rejestracji, następnie otrzymają Państwo wiadomość e-mail z linkiem do materiałów.

poniedziałek, 24 października 2022

Czy identyfikator loklany z pliku GML APP jest przenoszony do Zbioru APP?

W związku z powtarzającym się pytaniem:

Czy przy wygenerowaniu nowego GML APP pozostanie również pierwotny indywidualny identyfikator? Zgodnie z przepisami raz nadany identyfikator nie może ulec zmianie.

i wątpliwości, które pojawiły się na niedawnym spotkaniu z zakresu mpzp, zwracamy uwagę na treść następujących zapisów z rozporządzenia ws. zbiorów danych przestrzennych oraz metadanych w zakresie zagospodarowania przestrzennego:

§ 4.1

§ 5.1

Należy w tym miejscu rozróżnić dwa rodzaje identyfikatorów - identyfikator zbioru oraz identyfikatory obiektów znajdujących się w tym zbiorze (AktPlanowaniaPrzestrzennego, RysunekAktuPlanowaniaPrzestrzennego, DokumentFormalny).

a) W pierwszym przypadku (o którym mowa w § 4.1) identyfikator ma postać
  • przestrzeni nazw PL.ZIPPZP.<numer>
  • oraz kodu <jpt>-<rodzaj>
Pierwsza część to identyfikator zbioru danych widoczny w rejestrze EZiUDP, który został nadany po zgłoszeniu zbioru do GUGiK i dla danej jednostki jest stały i niezmienny. Druga część składa się z identyfikatora jednostki tj. 6 pierwszych znaków kodu TERYT oraz rodzaju zbioru (MPZP lub SUIKZP).

Przykładowy identyfikator zbioru danych dla mpzp dla miasta Otwock będzie miał następującą formę:

PL.ZIPPZP.7449/141702-MPZP

Wszystkie składowe identyfikatora zbioru danych na każdym etapie istnienia APP będą więc niezmienne.

b) Identyfikator obiektu (§ 5.1) składa się z elementów:
  • PL.ZIPPZP.<numer>/<jpt>-<rodzaj> (przestrzeń nazw, czyli identyfikator zbioru z pkt. a)
  • <id lokalny> identyfikator lokalny
  • <wersja> identyfikator wersji obiektu
Przykładowy identyfikator obiektu AktPlanowaniaPrzestrzennego dla planu w zbiorze danych mpzp dla Otwocka:

PL.ZIPPZP.7449/141702-MPZP/LX.652.22/P1/20220303T000000

Identyfikator lokalny oraz identyfikator wersji są nadawane przez dostawcę danych. W systemie e-mapa zgodnie z rekomendacją z dokumentu Specyfikacja danych „Planowanie przestrzenne” przy tworzeniu identyfikatora lokalnego wykorzystywane są numery uchwał przyjmujących dany akt planowania, a dla identyfikatora wersji - wartość elementu poczatekWersjiObiektu (data i czas) zgodnie ze schematem RRRRMMDDTHHMMSS.
Taka konwencja gwarantuje niezmienność i unikalność identyfikatorów w zbiorze, co jest wymogiem rozporządzenia.

Jednocześnie zapis w § 5.1 wyraźnie wskazuje, że identyfikator ten jest nadawany w chwili włączenia obiektu do zbioru danych. Dane APP na etapie projektowania (uchwalone przystąpienie) lub przyjęcia (podpisany plik GML wysłany do dziennika wojewódzkiego) nie należą do zbioru.
Dodatkowo zgodnie z bazą pytań i odpowiedzi na stronie ministerstwa:
Czy dokument elektroniczny GML dla uchwalonego APP włączany do zbioru danych APP to ten sam dokument, który stanowił załącznik do uchwały przyjmującej APP?

Nie. Podpisany dokument elektroniczny GML z finalnymi danymi przestrzennymi dla APP stanowiący załącznik do uchwały przyjmującej APP nie podlega modyfikacji. [...] 
Do zbioru danych APP należy włączyć kolejną wersję dokumentu elektronicznego GML

Tak więc do zbioru nie trafiają dane APP publikowane w dzienniku, ale ich nowa (uzupełniona) wersja. Wynika z tego wprost inna zawartość dokumentu, w tym inna wartość identyfikatora wersji opartego na czasie utworzenia/modyfikacji obiektu, jak również możliwe jest nadanie nowego identyfikatora lokalnego. I dopiero po włączeniu danych do zbioru pojawia się wymóg niezmienności lokalnego id.

Podsumowując:
Z przepisów nie wynika żaden wymóg, by identyfikator lokalny oraz identyfikator wersji obiektu APP w zbiorze były takie same jak identyfikatory danych obiektu na wcześniejszym etapie przed włączeniem do tego zbioru. Niezmienna musi być jedynie przestrzeń nazw czyli identyfikator zbioru.

piątek, 21 października 2022

Seminarium on-line z zakresu MPZP

20 października na platformie Zoom odbyło się spotkanie dla pracownic i pracowników urzędów miast i gmin, które poświęcone było wykorzystaniu systemu e-mapa w realizacji zadań samorządu - w szczególności w zakresie zagospodarowania przestrzennego.

W telekonferencji wzięło udział niemal 500 osób z całej Polski, w tym również z jednostek, które nie korzystały do tej pory z rozwiązań oferowanych przez naszą firmę.

Podczas pierwszej części spotkania omówiono tematykę infrastruktury danych przestrzennych w Polsce oraz ewidencji zbiorów i usług danych przestrzennych.

W kolejnym panelu zaprezentowano nowe i przydatne funkcjonalności portali e-mapa.net dla samorządów:

Następnie przedstawiono prezentacje:
  • Podstawy funkcjonowania planów miejscowych i studium oraz metody publikacji
  • Wypisy i wyrysy z MPZP
Po krótkiej przerwie pokazano w jaki sposób wykorzystać usługi przeglądania i pobierania znajdujące się w rejestrze EZiUDP.

Dużym zainteresowaniem cieszyła się kolejna część spotkania, w której przedstawiono problematykę przygotowania i zarządzania zbiorami APP dla planów i studium. Zaprezentowano w jaki sposób w systemie e-gmina wykonuje się czynności dotyczące przygotowania i publikacji danych z zakresu zagospodarowania przestrzennego - od wprowadzenia informacji o przystąpieniu do planu, przez generowanie plików GML do umieszczenia w dzienniku wojewódzkim, a kończąc na podpisaniu zbioru APP i publikacji w usłudze pobierania.

Na zakończenie omówiono usługi pobierania ATOM i WFS. Odniesiono się również do licznych wniosków i pism, trafiających do samorządów, w których porusza się prawidłowość różnych sposobów udostępniania zbiorów danych.

W czasie całego spotkania uczestnicy zadali kilkaset pytań, na które na bieżąco staraliśmy się odpowiadać. Pojawiło się również wiele podziękowań i głosów o przydatności tego typu telekonferencji.

Dziękujemy wszystkim za liczny udział i aktywne uczestnictwo!

Dla uczestników dostępne jest już nagranie całego spotkania*.
UPDATE: Do materiałów dodano również plik z listą pytań i odpowiedzi.
*Na stronie należy wpisać dane podane przy rejestracji, następnie otrzymają Państwo wiadomość e-mail z linkiem do materiałów.

ś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.