Do Stowarzyszenia Wikimedia Polska przyszło zaproszenie do zaopiniowania zmiany rozporządzenia o CRIP (Centralne Repozytorium Informacji Publicznej). Jest to tyle dla nas istotne, że w CRIP ma być masa danych geograficznych, które obligatoryjnie będą musiały tam wrzucić liczne instytucje państwowe i samorządowe. CRIP zasadniczo ma być stroną, która w przyjazny dla użytkownika sposób udostępnia i prezentuje te dane na zasadzie ustawy o dostępie do informacji publicznej, czyli w zasadzie te dane wpadają do domeny publicznej.
Widziałem z tzw. rozdzielnika, że OSM Polska nie został zaproszony do tego opiniowania, ale my chętnie zawrzemy w naszej opinii uwagi OSM Polska. W nowelizacji jest m.in. szczegółowa rozpiska harmonogramu i zakresu danych, które mają być do CRIP załadowane, a także detale techniczne w jakiej to formie będzie to składowane i udostępniane. Ktoś by był może zainteresowany napisaniem uwag z punktu widzenia OSM? Zainteresowanemu napisaniem opinii prześlę chętnie nadesłane kwity.
W mailu nie napisali, normalnie to są 2 tygodnie od daty wysłania zaproszenia, a to miało miejsce 26 września. Dostałem już informację, że zarząd OSM Polska się tym zajmie.
Jestem po lekturze rozporządzenia, obejrzałem portal: https://danepubliczne.gov.pl/ jeszcze chciałbym zajrzeć do ustawy. Ale moim zdaniem, jest dla nas pole do popisu.
Zasadnicze pytanie - czy można na etapie rozporządzenia wymusić na instytucjach, aby adresy zapisywały w ustalonym formacie? Zasadniczo obecnie nie ma schematu a wpisywane adresy np. Choszczewo 12 nie pozwalają na geolokalizację - takich miejscowości w PL może być 20. Najlepiej, aby w skali kraju ujednolicić zapisywanie takich rzeczy - np. Województwo,Powiat,Gmina,Miejscowość,Adres
Moim zdaniem od tego powinno być to rozporządzenie, by ujednolicić format przekazywanych danych, w tym również standardy kodowania adresów, tak by łatwo to można było automatem wyciągnąć. Możesz podzielić się linkiem do Etherpada, chętnie bym dołączył swoje przemyślenia.
W tym kontekście zapewne chodziło raczej o “jednoznaczne”.
Jednolite też by były dobre, przy czym na mój nos to się nie uda w 100%, czyli jeden sztywny schemat, natomiast w postaci schematu przewidującego kilka dobrze zdefiniowanych formatów, obejmujących wszystkie możliwe adresy w Polsce, to już jak najbardziej.
Mam na myśli to, że zapis adresu jest jednoznaczny. Jeżeli ograniczymy się do formatu CSV, który pojawia się w projekcie, to wyobrażam sobie to tak, że adres byłby zapisywany jako zestaw:
(obowiązkowo) województwo (wartość zgodna z Teryt)
(obowiązkowo) powiat (wartość zgodna z Teryt)
(obowiązkowo) gmina (wartość zgodna z Teryt)
(obowiązkowo) miejscowość (wartość zgodna z Teryt)
(opcjonalnie) ulica (wartość zgodna z Teryt)
(opcjonalnie?) numer posesji + numer lokalu
To mam nadzieję, że by pozwoliło na opisanie 99% adresów. Alternatywa, jaka przeszła mi przez myśl, to by adresy podawać w formie: szerokość geograficzna, długość geograficzna w układzie odniesienia <tu proszę o pomoc geodetę :-)>. Inny z pomysłów - to by podać po prostu identyfikator Teryt miejscowości lub ulicy (w zależności, na jakim poziomie adres jest zdefiniowany) + numer posesji + numer lokalu, i to pozwala też zlokalizować punkt - tylko niestety wymaga, by mieć Teryt pod ręką i nie jest za miłe dla ludzkiego oka.
Niestety - jednoznaczne by oznaczało, że za każdym razem adres można zapisać inaczej -np. raz podać kod pocztowy, miasto, ulicę, a raz podać nadrzędne jednostki terytorialne.
ja bym się trzymał adresów - są już w dokumentach, a jak urzędnicy albo ich stażyści się wezmą za spisywanie współrzędnych z google maps to się to źle skończy. Walnąć się w terycie też nietrudno, a poza tym dołoży to masę niepotrzebnej pracy którą może zrobić automat już na poziomie wykorzystywania tych informacji gdzie indziej.
Miałem już doświadczenie z wykazami Urzędu Komunikacji Elektronicznej, gdzie każda stacja nadawcza ma wpisane w pozwoleniu swoje współrzędne - połowa wypada na Bałtyku, część na Słowacji albo w Chinach
“Wylałem swoje żale” na Etherpadzie. W nowej wersji projektu rozporządzenia widać zmiany:
zmieniono np. udostępnienie granic administracyjnych z pliku CSV lub XLS, na KML lub shapefile
pojawiła się propozycja, by niektóre dane udostępniać w formacie pliku PDF (np wykaz przedsiębiorców z licencją na sprzedaż alkoholu)
PDF może i jest dopuszczalny, gdy mówimy o raportach, analizach i podsumowaniach - tylko czy ma ktoś pomysł na dobrą definicję granicy, pomiędzy danymi klasy wykaz, a klasy podsumowanie/analiza?
No i jeszcze pytanie, czy przypadkiem dla KML/Shapefile nie są potrzebne też bardziej szczegółowe wymagania, jak pliki powinny wyglądać, by łatwo było je wykorzystać.
Ja bym się tego XLS tak nie czepiał :). Mimo wszystko eksport danych nie jest aż tak ciężki, a w przypadku tabel ze skomplikowanymi polami (np. pola wieloliniowe, długie opisy) CSV jest ciężki w obsłudze i parsowaniu.
A ja bym się czepiał XLS. Jest od lat jakiś dokument zalecający w Polsce OpenDocument, nawet MS Office przez ten czas nauczył się go obsługiwać, więc wolałbym żeby był przejrzysty standard międzynarodowy niż firmowy “standard de facto”.
Dla pól wieloliniowych jest prosta - zamiast korzystać z CSV, można korzystać z: ASCII Delimited Text jako wariant DSV.
To rozwiązuje problem, że znak nowej linii jest znakiem specjalnym. To nawet daje się obsługiwać w Excelu, ale wymaga pierścienia wiedzy o Excelu Wydaje mi się, że w takim przypadku, lepiej będzie to zapakować w XML-a.
Excela o tyle nie lubię, że niektórym się wydaje, że jak zrobią połączone komórki, to już jest łatwo wywnioskować co się do czego odnosi, a na mój gust - to tu powinniśmy oczekiwać “raw data”.
Czy będzie to ODF czy Office Open XML, to jest to jedno zło, bo nadal w tych dokumentach jest więcej formatowania, niż struktury danych, co później utrudnia parsowanie.