zmiana rozporządzenia o CRIP

Hej,

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.

To ze nie zostal zaproszony nie znaczy, ze nie moze brac udzialu. Moim zdaniem wrecz powinien :slight_smile:

Materiały są do pobrania tutaj:

https://m.mac.gov.pl/konsultacje/rozporzadzenie-w-sprawie-nowych-zasobow-do-centralnego-repozytorium-informacji

Czas jest do 10 czy do 17 października? Serwis podaje dwie daty. …

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.

Eee, jeśli tylko masz na myśli moją prośbę o podesłanie kwitów, to zbyt szybko wyciągasz wnioski, że zarząd się tym zajmie :wink:

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.

Ktoś jeszcze się temu przyglądał?

Przeklejam to co napisałem na etherpadzie:

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.

To jeszcze jeżeli chodzi o materiały, to polecam:
jednolity tekst ustawy o dostępie do informacji publicznej

W szczególności artykuł 9:

(Pogrubienie moje)

Moim zdaniem, można się powołać na ten zapis, by wymusić jednolite kodowanie adresów.

Co masz na mysli?
Pozdrowienia,
Marek

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.

http://etherpad.wikimedia.org/p/CRIP_MAIC

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 :wink:

“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 :slight_smile: 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.

Oczywiście, że im prościej, tym lepiej, ale jeśli by się nie dało prościej, to dla mnie jednak jest wyraźna różnica między tymi złożonymi formatami.