Walidacja plików APP GML za pomocą schematu XSD.

1.Narzędzia Ministerstwa Rozwoju i Technologii do kontroli poprawności plików GML APP.

Ministerstwo przygotowując się do procesu cyfryzacji planowania przestrzennego przygotowało i opublikowało narzędzia, którymi gminy miały tworzyć i kontrolować pliki GML zgodne z założeniami ministerstwa dotyczącymi tworzenia plików i zbiorów APP.

Jest to walidator danych APP dostępny na stronie https://www.gov.pl/web/gov/sprawdz-poprawnosc-danych-przestrzennych-oraz-metadanych którego zadaniem jest sprawdzać już przygotowane w innych narzędziach pliki GML w postaci APP oraz wtyczka APP, której zadaniem było ułatwienie tworzenia i kontroli plików GML w środowisku Qgis.

Niestety życie pokazuje, że często jest tak, że walidator na stronie ministerstwa waliduje pliki, a we wtyczce się nie walidują lub jest odwrotnie.

Z punktu widzenia zwykłych użytkowników tych danych ważne jest czy plik GML z załącznika uchwały lub strony da się w sposób prosty i bezproblemowy otworzyć np. w Qgis poprzez przeciągnięcie do okna programu.

Dla użytkowników bardziej zaawansowanych istotna jest informatyczna zgodność ze schematem XSD plików XML szczególnie, że przy bardziej zaawansowanych systemach wymagana jest walidacja danych XML w celu zapewnienia zgodności ze strukturą bazy danych przed importem danych do systemu.

2. Narzędzia do walidacji XML schematem XSD.

Omijając narzędzia ministerstwa wykonałem masową walidację całego katalogu wszystkich pobranych plików GML APP opisanych w poprzednim artykule za pomocą niezależnych narzędzi informatycznych. Są to standardowe moduły walidatorów XML zawarte w pakiecie Python oraz niezależnie biblioteki umożliwiające walidację zawarte we frameworku .NET.

Czytelnik może wykonać walidację pojedynczego pliku XML za pomocą darmowego Notepad++ z wtyczką XML Tools. Należy wywołać polecenie z menu Wtyczki > XML Tools > Validate Now. Należy otworzyć plik XML do walidacji i uruchomić to polecenie a następnie kilkanaście sekund poczekać na wynik ponieważ walidator będzie pobierał zewnętrzny plik XSD niezbędny do działania. Wyświetli się informacja, że plik jest poprawny lub informacja o błędzie walidacji zaznaczona w notepad++ w oknie pliku.

3. Walidacja danych APP – problemy ze schematem planowaniePrzestrzenne.xsd

Walidacja dla pobranych plików APP GML schematem planowaniePrzestrzenne.xsd ze strony ministerstwa dała następujący wynik:

Przyczyną wystąpienia takiego błędu walidacji był błąd w schemacie danych XSD opublikowanym przez ministerstwo.

Element '{http://www.opengis.net/wfs/2.0}FeatureCollection’: No matching global declaration available for the validation root.

Poprawiłem przyczynę tego błędu nie modyfikując zakresu kontrolowanych nim danych i ponownie wykonałem walidację plików.

Tym razem wynik był następujący:

Nadal jednak wiele plików nie walidowało się narzędziami standardowymi mimo, że na stronie walidatora ministerstwa pokazywało dla przykładowych plików XML, że są zgodne ze schematem.

4. Rodzaje i typy błędów walidacji w plikach APP

Szczegółowa analiza pokazała, że głównym problemem uniemożliwiającym walidacje było to, że w plikach APP występują dodatkowe znaczniki wynikające z podpisów cyfrowych, które są niezgodne z opublikowanym schematem planowaniePrzestrzenne.xsd a z nieznanych powodów walidator ministerstwa na stronie internetowej tych błędów nie zauważa i nie raportuje. Błędy walidacji raportowane są za to we wtyczceAPP dla Qgis, którą ministerstwo zamówiło.

Innymi słowy ministerstwo tworząc schemat danych nie umieściło w jego strukturze elementów, które odpowiadają za prawidłowy podpis cyfrowy, więc wszystkie podpisane wewnętrznym podpisem pliki APP nie walidują się ze schematem.

W zależności od sposobu zdefiniowania podpisu w pliku XML mamy do czynienia z różnymi skutkami takiego działania.

5. Przykładowe typy błędów walidacji i opis ich skutków:

a) Błąd walidacji – dodany podpis cyfrowy element Signature jako podelement. Przykład pliku

Raport błędu walidatora:

Element '{http://www.w3.org/2000/09/xmldsig#}Signature’: This element is not expected.

W przypadku takiego opisu błędu mamy do czynienia z podpisem cyfrowym, który został dodany do elementu głównego jako ostatni podelement. Występuje w kilku tysiącach pobranych plików GML.

Skutek tego błędu walidacji:

– wynik walidacji XSD standardowe oprogramowanie – nie waliduje się

– wynik walidacji XSD wtyczka – nie waliduje się

– wynik walidacji XSD strona ministerstwa – waliduje się

– Qgis – pliki się czytają

b) Błąd walidacji – dodany podpis cyfrowy otaczający treść XML. Przykład pliku

Raport błędu walidatora:

Element 'Signatures’: No matching global declaration available for the validation root.

W przypadku takiego opisu do pliku XML dodano podpis cyfrowy otaczający który otacza całą treść GML. Efektem tego jest brak możliwości zarówno walidacji jak i rozpoznania pliku GML przez oprogramowanie GIS.

Skutek tego błędu walidacji:

– wynik walidacji XSD standardowe oprogramowanie – nie waliduje się

– wynik walidacji XSD wtyczka – nie waliduje się

– wynik walidacji XSD strona ministerstwa – nie waliduje się

– Qgis – pliki się nie czytają

c) Błąd walidacji – dodany podpis cyfrowy, który umieszcza źródłowy XML w pliku binarnym. Przykład pliku

Podpis cyfrowy w którym plik GML zostanie zapisany w pliku binarnym jest nie do odczytu zarówno przez człowieka wzrokowo, jak i przez narzędzia GIS jak i walidatory ze względu na to że jego zawartość jest ukrywana w kodowaniu Base64 w środku pliku. Taki plik bez rozkodowania jest dla ludzi najbardziej kłopotliwy.

Skutek tego błędu walidacji:

– wynik walidacji XSD standardowe oprogramowanie – nie waliduje się

– wynik walidacji XSD wtyczka – nie waliduje się

– wynik walidacji XSD strona ministerstwa – nie waliduje się

– Qgis – pliki się nie czytają

d) Pozostałe błędy walidacji:

Raport błędu walidatora:

Element '{http://www.opengis.net/gml}FeatureCollection’: No matching global declaration available for the validation root

Ten typ błędu oznacza, że plik został zapisany w Qgis poprzez polecenie zapisz jako GML w przestrzeni nazw ogr bez schematu planowanie przestrzenne.

Raport błędu walidatora:

Element '{http://www.isotc211.org/2005/gmx}Anchor’: This element is not expected.

Powyższy typ błędu oznacza że jako załącznik został umieszczony plik z metadanymi zamiast GML z APP

Istnieje jeszcze wiele innych błędów walidacji w znaczącej części dotyczących sposobu generowania gml:id dla elementu app:AktPlanowaniaPrzestrzennego i występowania w nim znaków, które nie powinny tam występować czyli spacji, ukośników i innych niedozwolonych znaków.

6. Wniosek dotyczący podpisu cyfrowego i walidacji.

W chwili obecnej jedynym podpisem spełniającym wymogi schematu planowanie przestrzenne w wersji 1.0 jest zewnętrzny podpis XADES dla pliku GML.

Mimo różnych informacji w internecie w tym zalecenia ministerstwa żeby umieścić plik wewnątrz XML czy porady http://files.abcpro.pl/static/legislator/version/2.3.0.0.12/obsluga-plikow-gml.html lub firm informatycznych wskazujących jak to zrobić, umieszczenie podpisu cyfrowego w środku pliku XML spowoduje brak możliwości jego walidacji standardowymi narzędziami informatycznymi, a więc niezgodność z prawem. W niektórych wypadkach (podpis otaczający lub binarny zapis pliku) spowoduje również brak czytania plików GML przez standardowe oprogramowanie GIS.

Fakt „usprawnienia” walidatora APP na stronie ministerstwa żeby tego błędu nie widział, nie oznacza że nie zobaczą go narzędzia i systemy, które będą próbowały tych danych użyć.

Uprzejmie proszę o rozwiązanie tego problemu przez ministerstwo.

Koniec części drugiej