Talk:Pl:Importy oficjalnych danych państwowych/Adresy

From OpenStreetMap Wiki
Jump to navigation Jump to search

Propozycja aktualizacji zaimportowanych adresów

Dane źródłowe

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 budnku?
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)

Propozycja tagowania

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:teryt TERYT_MIEJSCOWOSCI Miejscowość (Id GUS) identyfikator miejscowości, w której występuje adres
addr:place:teryt 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:teryt TERYT_ULICY Nazwa ulicy (Id GUS) identyfikator ulicy adresu
ref:addr IDENTYFIKATOR_PUNKTU idIIP identyfikator punktu

Kwestie dyskusyjne:

Podawanie teryt:simc pozwala nam lepiej wyłapac 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 teryt:symul pozwala a automatyczne budowanie słownika postaci tekstowej OSM dla nazwy ulicy na podstawie danych znajdującyc 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.

ref:addr - zapisywanie tego identyfikatora w OSM pozwoli nam jednoznacznie zidentyfikować punkt adresowy z danymi źródłowymi. W związku z tym, w sytuacji gdy:

  • pozycja punktu, który został przesunięty w OSM po imporcie, zostanie zachowana
  • w przypadku importów z GUGiK, możemy dokładnie wyliczyć, jakie zmiany zaszły pomiędzy wersją zaimportowaną, a obecną w danych

źródłowych - dzięki temu - można sprawdzić, czy zmieniła się nazwa ulicy/miejscowości/numer domu i w tym przypadku - nanieść te zmiany na 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 mapowiczów OSM
  • zminimalizować analizę danych, którą robi mapowicz 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 5m lub budynków zawierających punkt adresowy lub znajdujących się nie dalej niż 10m 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ż 100m 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ż 50m od daych 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 torelancji(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.

Dalsze kroki

  1. Uruchomienie stronki ze statystykami - ile punktów ulegnie modyfikacji, ile punktów zostanie dodanych, ile punktów z fixme, dla wszystkich gmin w Polsce. Przy założeniu, że w ciągu dnia będzie sprawdzane 50 gmin, to każda gmina będzie weryfikowana raz na dwa miesiące
  2. Uzupełnienie ref:addr dla punktów adresowych (wiąże się to z pierwszym przejściem skryptu przez wszystkie gminy przy wsparciu człowieka)
  3. Weryfikacja - czy przy posługiwaniu się ref:addr, można przejść na tryb automatyczny wgrywania zmian przez skrypt

Komunikacja ze skryptem

Zdarzają się błędy w danych źródłowych, których nie chcemy wielokrotnie poprawiać w OSM. Do tej pory spotkałem się z błędami:

  • błędne nazewnictwo ulic/miejscowości
  • błędna numeracja
  • wielokrotne adresy nadane dla budynku (często przez różne gminy)
  • błędnie ulokowane punkty adresowe (np. daleko poza granicami gminy)

Pierwsze dwa punkty bieżący skrypt już jest w stanie wyłapać. Ostatnich dwóch - nie. Natomiast przy wykorzystaniu ref:addr, można zastosować protokół, w którym po imporcie danych, jeżeli mapowicz uzna, że adres nie powinien się znajdować w miejscu importu (błędy typu duplikat, albo daleko poza granicami gminy), to usuwa wszystkie tagi z punktu poza ref:addr i source:addr. Taki punkt automat będzie mógł usunąć, w momencie w którym zniknie on z danych źródłowych.