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

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.