Walidacja plików XML/GML – dlaczego jest potrzebna ?

Jak już wspomniałem na tym blogu walidacja danych xml / gml za pomocą schematu XSD polega na sprawdzeniu zgodności struktury i warunków zapisanych w schemacie z zapisanymi w pliku xml zagnieżdżeniami i wartościami atrybutów oraz elementów.

Walidacja jest operacją automatyczną sprawdzającą plik i dającą jednoznaczny wynik „spełnia” lub „nie spełnia”. Nie powinno się dać również w procesie walidacji wyłączyć warunków ze schematu nie zmieniając go. Gwarantuje to z dość dużą pewnością że pliki XML, które przejdą walidacje niezależnie od walidatora, którego użyjemy spełniają wytyczne zawarte w schemacie XSD.

Wszystkie „walidatory” lub pseudowalidatory, których działanie oparte jest o zapisane i możliwe do włączenia lub wyłączenia warunki nie spełniają kryterium walidatora i nie powinny być walidatorem nazywane. Włączając w to np. walidator GUGiK do danych EGiB. Ale o tym jeszcze szerzej napiszę.

Dzisiaj na przykładzie pokażę co się dzieje jeśli będziemy przetwarzać nie zwalidowany plik gml z błędami zapisu geometrii w systemie, który jest przygotowany do otrzymania pełnowartościowego pliku GML.

Jako dane do walidacji użyję do walidacji danych adresowych w formacie GML z systemu IMPA Geo-Systemu dla całości Polski dostępnych na stronie http://danepubliczne.punktyadresowe.pl/ dostęp 03.07.2018r.

Schemat użyty do walidacji to schemat, który opisałem tutaj z aktualnej wersji wytycznych GUGiKu.

Do walidacji posłuży dość prosty programik, który kiedyś napisałem w .NET, a który wykorzystuje standardowo opracowane przez Microsoft polecenia w tym języku służące do walidacji plików XML. Dopisałem tylko funkcjonalność wytwarzania plików GML z błędnymi nie zwalidowanymi obiektami, które wykazuje walidator. Do wizualizacji plików standardowo posłuży nam Qgis.

Film z walidacji:

W wyniku walidacji danych otrzymałem trzy pliki, w których pojedyncze znaczniki geometrii walidator wykazuje jako błędne. Są to pliki z gmin Kostrzyn, Mirosławiec i Torzym – oryginały plików dostępne tutaj. We wszystkich przypadkach błędne są elementy powierzchniowe ulic. Raporty do pobrania – walidacja_emuia

Z błędów walidacji można wyczytać ze w obiektach w tych plikach występują nieprawidłowe znaczniki, których nie ma w schemacie GML. Oznacza to, że programy czytające GML nie będą w stanie przeczytać geometrii ponieważ jest ona zapisana w sposób dla nich niezrozumiały.

Próba wczytania danych dla powierzchniowych ulic z pliku z miejscowości Kostrzyn do Qgis pokazuje obiekt, ale jego geometria w błędnym elemencie jest niedostępna dla programu.

Ciekawiej robi się gdy spróbujemy wytworzyć na takich danych np bufor za pomocą polecenia Wektor > Narzędzia Geoprocessingu > Bufor o stałej szerokości. W wyniku przetwarzania nieprawidłowo zagnieżdżonych danych, obiekt który jest nieprawidłowy znika i z początkowych 4 obiektów zostają nam tylko 3.

Wnioski: Zanim zaczniecie przetwarzać dane z plików GML upewnijcie się ze są one poprawne. Walidacja do schematu powinna być więc przy przetwarzaniu GML elementem obowiązkowym. Przetwarzanie danych nie walidujących się ze schematem GML może powodować problemy w tym np. znikanie danych lub nieprawidłowe wyniki analiz przestrzennych lub eksportu.

Aktualizacja 17-07-2018:

Wyniki walidacji dla darmowych danych GUGiK BDOO, PRG, PRNG, Punkty adresowe – błędy w raportach txt i odpowiadajacych im obiekty w plikach GML:

GML Adresy z PRG wersja 16.07.2018

GML Jednostki administracyjne PRG wersja 06.03.2018 – Błędne schematy danych na stronie gugik.gov.pl

GML PRNG miejscowości wersja 09.07.2018

Błędy walidacji nie wskazują na problemy z zapisem geometrii. Głównym problemem są nieprawidłowe znaki w gml:id niezgodne ze schematem. Nie oznacza to jednak że geometria jest prawidłowa bo jej zapis jest zgodny ze schematem. Więcej np. na http://nycz.beskidy.pl/2018/04/06/naprawiamy-geometrie/

Należy jednak pamiętać że zasady poprawności geometrii mogą się różnić dla Postgisa i np. bazy Oracle.