Pl:Importy oficjalnych danych państwowych/Adresy

From OpenStreetMap Wiki
Jump to navigation Jump to search

Cele

Import punktów adresowych na obszarze całej Polski.

Harmonogram

Brak specyficznego, kolejne importy zwykle pokrywające gminę, lista:

Import

Źródło danych

W naszym amatorskim rozumieniu prawa, dane są dostępne przez (samo)rządowy projekt EMUiA i w naszym rozumieniu prawa podpadają pod ustawę o dostępie do Informacji publicznej, czyli są publikowane w Domenie Publicznej.

Użyte oprogramowanie

Zestaw skryptów pomocny przy pracy z importami adresów znajduje się w repozytorium. Najważniejsze są dwa skrypty:

  • merger.py - pobierający adresy oraz dane z OSM i łączący te dane
  • punktyadresowe_import.py - pobierający dane adresowe i zapisuje je do pliku

Obsługiwane źródła danych:

Uruchamianie merger.py

Ewidencja adresów jest prowadzona przez gminy. Skrypt importujący też działa na poziomie konkretnej gminy. Gminę, na której pracujemy definiujemy przez podanie opcji --terc <GMINA> z kodem TERC ze słowika TERYT danej gminy. Dla serwisów prowadzonych przez iMPA kod terc jest zgadywany przez skrypt.

Źródło wybiera się podając odpowiednią opcję:

  • --impa <nazwa serwisu> dla serwisów iMPA
  • --gisnet <nazwa serwisu> dla serwisów GISNET
  • --gugik_gml <ścieżka do pliku GML> dla importów z plików GML GUGiK
  • --gugik dla importu z EMUiA
  • --warszawa dla importu z UM Warszawa + EMUiA

Standardowo skrypt generuje plik wyjściowy result.osm, można podać też własną nazwę pliku za pomocą --output <nazwa pliku>.

Skrypt jest też dostępny przez usługę sieciową. Można pobrać plik poprzez otworzenie adresu:

Praca z danymi wygenerowanymi przez skrypt

W przypadku gdy skrypt nie jest w stanie podjąć decyzji, w jaki sposób połączyć dane, skrypt dodaje tag fixme do takich punktów adresowych.

Przypadki:

  • ten sam adres (miejscowość + ulica + numer) występuje więcej niż jeden raz w danych źródłowych, dodatkowo oznaczane, gdy są oddalone od siebie o więcej niż 100 metrów
  • w danej miejscowości występują adresy z ulicami oraz bez ulic
  • w odległości mniejszej niż 5m od importowanego adresu istnieje w OSM adres o takiej samej miejscowości i numerze, ale innej nazwie ulicy. Nazwa ulicy w pliku wynikowym będzie miała nazwę z OSM
  • w odległości mniejszej niż 5m od importowanego adresu istnieje w OSM adres o takiej samej miejscowości i nazwie ulicy, ale o innym numerze. Numer w pliku wynikowym będzie miał wartość z importu
  • punkt w OSM znajduje się co najmniej 50m od punktu w danych źródłowych, zostanie stworzony nowy punkt w pliku wynikowym w miejscu wskazanym przez dane źródłowe
  • adres jest w OSM, ale nie ma go w danych źródłowych

Mapowanie danych źródłowych na OSM

iMPA

Przykładowe dane o punkcie adresowym z danych iMPA, pobrane za pomocą:

  • REQUEST=GetFeatureInfo
  • QUERY_LAYERS=punkty
  • INFO_FORMAT=text/html

Z serwisu WMS: http://www.punktyadresowe.pl/cgi-bin/mapserv?map=/home/www/impa2/wms/sorkwity.map

Nazwa kolumny wartość komentarz
Miejscowość (Id GUS) Sorkwity (0488119) W nawiasie podany jest SIMC miejscowości
Nazwa ulicy (Id GUS) Szkolna (21970) W nawiasie podany jest SYM_UL ulicy
Numer 1
Kod pocztowy 11-731
Obręb 0015
Działka 72/5
PUWG 1992 Y 640353, X 666490 Współrzędne punktu adresowego w PUWG 1992
GPS (WGS 84) L 21.13400, B 53.84404 Współrzędne punktu adresowego w WGS84
Data zmiany 2014-02-28 09:48:05 Data ostatniej zmiany punktu
idIIP 81fd091f-5012-46ed-a4e7-fa6d23306a0a Identyfikator punktu adresowego
Źródło danych sorkwity.e-mapa.net


GUGiK

Przykładowe dane o jednym punkcie adresowym:

Nazwa kolumny wersja 8 wersja 9 komentarz
IDENTYFIKATOR_PUNKTU N/A.30000000000033106180.8 N/A.30000000000033106180.9 Numer wersji znajduje się po kropce. Występują adresy o nieciągłej numeracji wersji
IDENTYFIKATOR_DZIALKI <brak jednoski>.<brak obrębu>. <brak jednoski>.<brak obrębu>. Numer ewidencyjny działki, nie zawsze występuje (tak jak np. w tym przypadku)
IDENTYFIKATOR_ULICY N/A.20000000000000751840.9 Identyfikator ulicy pojawia się w wersji 9 (wcześniej adres był bez ulicy)
TERYT_ULICY 20254 Identyfikator ulicy TERYT (czyli SYM_UL z Terytowego słownika ULIC)
IDENTYFIKATOR_MIEJSCOWOSCI PL.PZGiK.204.10000000000000377213.8 PL.PZGiK.204.10000000000000377213.9 Do weryfikacji, czy identyfikator zmienia się wraz ze zmianą miejscowości bez ulic na miejscowość z ulicami
TERYT_MIEJSCOWOSCI 0971057 0971057 Identyfikator SIMC z Terytowego słownika SIMC
TERYT_JEDNOSTKI 3021103 3021103 Identyfiaktor TERC (województwo, powiat, gmina + rodzaj gminy) ze słownika TERC
NAZWA_MIEJSCOWOSCI Mosina Mosina
NAZWA_ULICY Słoneczna Nazwa ulicy pojawia się w wersji 9
STATUS Zatwierdzony Zatwierdzony Status punktu. Zidentyfikowano: Zatwierdzony, TODO:
NUMER_PORZADKOWY 33 33 Numer budynku
KOD_POCZTOWY 00-000 00-000 Jak widać, nie zawsze uzupełniony
ELEMENT_BUDYNKU Środek ciężkości budynku Środek ciężkości budynku Umieszczenie punktu adresowego w budynku?
USYTUOWANIE_BUDYNKU Budynek naziemny Budynek naziemny
STATUS_BUDYNKU Istniejący Istniejący Zidentyfikowano wartości: Istniejący, TODO:
WERSJA_OD 2013-08-02 12:49 2013-08-02 12:51 Od kiedy obowiązuje wersja w formacie dla ludzi
WERSJA_DO 2013-08-02 12:51 do kiedy obowiązywała wersja. W ostatniej wersji - pole nie występuje
KOMENTARZ_WERSJI Wersja powstała w wyniku aktualizacji miejscowości. Wersja powstała w wyniku aktualizacji miejscowości.
BRAK_WAZNY_OD Brak danych Brak danych W niektórych sytuacjach (wydaje się, że dotyczy to konkretnych pól), brak wartości jest przekazywane poprzez prefiks BRAK_ w nazwie pola
OD 1375447796000 1375447863000 Od kiedy obowiązuje punkt w formacie timestamp
DO 1375447863000 Do kiedy obowiązuje punkt w formacie timestamp. Brak pola dla ostatniej wersji.

Na tym przykładzie widać, jak zmieniają się dane w przypadku zmiany ulicy. Dane zostały pobrane wykorzystując:

  • FORMAT=application/vnd.google-earth.kml+xml
  • LAYERS=emuia:layer_adresy_labels
  • REQUEST=GetMap

z WMS EMUiA GUGiK (http://emuia.gugik.gov.pl/wmsproxy/emuia/wms)


Tagowanie

tag OSM dane GUGiK dane iMPA komentarz
addr:city NAZWA_MIEJSCOWOSCI Miejscowość (Id GUS)
addr:place NAZWA_MIEJSCOWOSCI Miejscowość (Id GUS) w przypadku, gdy nie występuje addr:city
addr:street NAZWA_ULICY Nazwa ulicy (Id GUS)
addr:postcode KOD_POCZTOWY Kod pocztowy o ile występuje i jest różny od 00-000
addr:housenumber NUMER_PORZADKOWY Numer z usunięciem spacji, ale bez zmiany wielkości liter
source:addr "emuia.gugik.gov.pl" Źródło danych
addr:city:simc TERYT_MIEJSCOWOSCI Miejscowość (Id GUS) identyfikator miejscowości, w której występuje adres
addr:place:simc TERYT_MIEJSCOWOSCI Miejscowość (Id GUS) identyfikator miejscowości, w której występuje adres, gdy nie występuje addr:city/addr:city:teryt
addr:street:sym_ul TERYT_ULICY Nazwa ulicy (Id GUS) identyfikator ulicy adresu
ref:addr IDENTYFIKATOR_PUNKTU idIIP identyfikator punktu

Kwestie dyskusyjne:

Podawanie addr:city:simc pozwala nam lepiej wyłapać brakujące palce=*, bo nie bazujemy na powtarzających się nazwach, tylko możemy sprawdzać odległość do konkretnej miejscowości, o którą w danym przypadku chodzi.

Podawanie addr:street:symul pozwala a automatyczne budowanie słownika postaci tekstowej OSM dla nazwy ulicy na podstawie danych znajdujących się w OSM, zamiast budować sztuczne mapowanie w skryptach. Dzięki temu też w przypadku pojawiania się nowych adresów przy danej ulicy, automatycznie zostanie wykorzystana nazwa, jaka już występuje dla danego teryt:symul w OSM.


Mechanizm importu

Mechanizm importu opiera się o skrypt merger.py (https://github.com/wiktorn/osm-addr-tools). Mechanizm importu został dopracowany na importach adresów w ~100 gminach, w których już były zaimportowane adresy. Cele były następujące:

  • pozostawić zmiany naniesione przez mapujących OSM
  • zminimalizować analizę danych, którą robi mapujący robiący import

Algorytm działa następująco:

  1. Ładuje wszystkie adresy dla gminy z danych źródłowych (GUGiK, iMPA) (dla GUGiK wykorzystywana jest granica w OSM do wyznaczenia, które adresy zostaną załadowane, w przypadku iMPA - ładowane są wszystkie adresy z serwisu). W ramach ładowania danych ze źródła wykonywane są operacje:
    1. mapowania nazw ulic oraz miejscowości na zgodne ze standardem OSM. Na podstawie statycznych tabel mapujących oraz dynamicznie budowanych słowników w oparciu o dane w OSM zawierające teryt:symul
    2. wyszukiwane są zduplikowane adresy w danych źródłowych tj. występują powtórzenia trójek (nazwa miejscowości, nazwa ulicy, numer). Takie adresy oznaczane są fixme "Duplicate address in import"
    3. wyszukiwane są adresy w miejscowościach o mieszanym schemacie adresowania - z ulicami oraz bez ulic. Wszystkie adresy bez ulic oznaczane są fixme "Mixed addressing scheme in city - with streets and without. %.1f%% (%d) with streets." - przy czym pod pierwszą wartość podstawiana jest wartość procentowa (ile punktów występuje z ulicą) a pod drugą (w nawiasie) - wartość bezwzględna
  2. Ładuje wszystkie adresy dla gminy z OSM w ramach BBOX wyznaczonym przez wszystkie zaimportowane adresy (dzięki temu ładowane są również adresy spoza granicy gminy - pozwala to na uniknięcie duplikowania adresów przy granicach gmin)
  3. Adresy z obu źródeł są indeksowane za pomocą trójki: (nazwa miejscowości, nazwa ulicy, numer)
  4. Dla każdego adresu z danych źródłowych są wykonywane operacje:
    1. fix_similar_addr - szuka punktów adresowych w odległości 5 m lub budynków zawierających punkt adresowy lub znajdujących się nie dalej niż 10 m i zmienia wartości nazwy ulic w danych importowanych na nazwę z OSM. Modyfikuje również wartość addr:housenumber w danych OSM na wartość z importu
    2. próbuje wykonać łączenie danych za pomocą jednego z algorytmów
      1. do_merger_by_existing - szuka adresów o takiej samej wartości adresu (nazwa miejscowości, nazwa ulicy, numer). Punkty znajdujące się w odległości większej niż 100 m od pozycji z importu dostają tag fixme: "Node is %d meters away from imported point". W takiej sytuacji, punkty o odległości mniejszej niż 100m będą widoczne w pliku widokowym, niezależnie od tego, czy były zmienione w procesie. Jeżeli najbliższy punkt leży dalej niż 50 m od danych w imporcie, tworzony jest punkt adresowy, w przeciwnym wypadku - aktualizowany jest najbliższy punkt adresowy (pozostałe zostają bez zmian)
      2. do_merge_by_within - poszukuje budynków, w ramach których znajduje się punkt z importu. Jeżeli jest taki budynek i nie ma adresu, to tworzony jest punkt adresowy (zostanie potencjalnie złączony z obrysem w końcowej fazie). Jeżeli na budynku jest adres i jest on podobny do adresu z importu, budynek jest aktualizowany danymi z importu, a jeżeli nie - to tworzony jest dodatkowy punkt adresowy w ramach budynku
      3. do_merge_by_nearest - poszukuje najbliższych punktów. Jeżeli w promieniu 2m znajdzie się adres o takim samym addr:housenumber i pozostałych wartościach "podobnych", to jest aktualizowany danymi z importu. Jeżeli nie są podobne, to takie adresy są POMIJANE w imporcie.
      4. do_merge_create_point - tworzy punkt w miejscu importu
    3. Jeżeli nie zrezygnowano z łączenia adresów z obrysami budynków, jest wykonywany proces łączenia adresów z budynkami. W procesie, poszukiwane są budynki, które w swoim obrysie mają tylko jeden adres, i wtedy tagi z adresu przenoszone są na budynek. Dokonywane to jest na wszystkich adresach stworzonych w procesie do tego momentu oraz na adresach załadowanych z OSM. Po połączeniu wszystkich budynków proces jest powtarzany z zastosowaniem bufora tolerancji (budynki są powiększane w każdym kierunku) 2 i 5 (%?)
    4. Oznaczane są wszystkie nieistniejące adresy (tj. występują w OSM w granicach gminy, ale nie ma ich w danych źródłowych) i oznaczane fixme "Check address existance"

Jak widać algorytm w tej chwili nie korzysta z ref:addr, ale w momencie gdy zaczniemy go importować, to pierwszym algorytmem łącznia powinno być łączenie po ref:addr.


Przygotowywanie danych

Dane do importu są generowane poprzez przetworzenie WMSowych plików png dla których każdy wykryty punkt adresowy jest odpytywany ( przykładowe zapytanie) Wyniki są zapisywane w plikach *.osm dla dalszego przetwarzania. Punkty adresowe są filtrowane aby nie przykryć żadnego dotychczasowego punktu adresowego w danym obszarze, co pozawala uniknąć przesunięcia/skasowania/zduplikowania istniejącego punktu adresowego. Jeśli pozostałe punkty adresowe pokrywają się z istniejącym obrysem budynku, tagi adresowe zostają przypisane do istniejącego budynku. Dane są wyciągane w na tyle małych partiach że pozwala to je przejrzeć w JOSM przed ostatecznym importem. Do przegotowywania danych należy użyć reguł walidatora w JOSM: https://raw.githubusercontent.com/zibik/adresy_walidator/master/skroty.mapcss

Tagowanie

Tylko tagi punktów adresowych (:addr=* ) są dodawane podczas importu.

Przykładowe pliki importu

http://openstreetmap.org.pl/emuia-demo/siemiatycze-numerki.osm.bz2 - plik z danymi adresowymi otrzymany dzięki skryptowi użytkownika gsapijaszko.

http://openstreetmap.org.pl/emuia-demo/siemiatycze-filtered.osm.bz2 - plik po odfiltrowaniu adresów już wprowadzonych do OSM. Filtracja odbywa się z użyciem skryptu addrmerge.py.

http://openstreetmap.org.pl/emuia-demo/siemiatycze-after-merging.osm.bz2 - gotowe do wysłania dane, po połączeniu pliku siemiatycze-filtered.osm z istniejącymi w OSM obrysami budynków. Łączenie adresów z budynkami odbywa się z użyciem skryptu merge-building-addrs.py

Konto użytkownika z którego będzie wykonany import

Importy są przeprowadzanie z osobnych kont służących tylko do tego celu. Takie jest wymaganie DWG i nieprzestrzeganie go może skończyć się zawieszeniem konta czy usunięciem importowanych danych.

Lista wykonanych importów

Kompletna lista importów jest dostępna i tam należy dodawać wykonane importy.

Linki warte przejrzenia