I chciałbym to w najbliższym czasie przenieść na główną stroną dotyczącą importów, a w szczególności:
schemat tagowania
komunikację ze skryptem importującym
Dalsze kroki jakie planuję, to odpalić skrypt importujący dla wszystkich gmin w Polsce i wystawić statystyki dla takich uruchomień na stronce, wraz z linkiem do wygenerowanego pliku, by można w większej grupie zacząć pracować nad aktualizacją adresów.
Ja tylko zapytam, czy taki import (ponowny) będzie sprawdzał czy w danym punkcie jest już adres i jeżeli jest to poleci do następnego, czy też sprawdzi obecność danych adresowych i jeżeli są inne niż w pliku importowanym, to je poprawi. A co w przypadku gdy punkt adresowy jest w danych OSM a nie ma go na stronie urzędowej?
Zgodnie z opisem algorytmu (który może jest nieprzejrzysty), to generalnie jest robiona weryfikacja, czy w pobliżu (w promieniu 2m) nie ma jakiegoś adresu. W takiej sytuacji, skrypt poprawi numer domu (jeżeli różni się o wielkość liter, spacje itp.) w OSM, natomiast przejmie nazwę z OSM.
Jeżeli punkt adresowy jest w danych OSM, a nie ma go w danych urzędowych, oznaczany jest fixme=“Check address existance”. Tutaj można to jeszcze udoskonalić, o weryfikację, z jakiego źródła pochodzi adres i nie oznaczać adresów, które pochodzą z importu z innych serwisów (w przypadku importu z innego źródła niż EMUiA GUGiK).
Pytałem dlatego, ponieważ w “mojej” gminie w systemie e-mapa mam kilka przypadków tzw. “baboli”, czyli adresów, które do systemu e-mapa zostały źle wprowadzone. Pisałem do operatora maile z informacjami o nieprawidłowościach, ale pozostały bez echa (pomimo konieczności potwierdzenia każdego zgłoszenia niezależnie poprzez email). Stąd moje zapytanie, bo już raz po imporcie punktów adresowych przez Zibiego poprawiałem te adresy ręcznie i nie chciałbym do tego wracać, bo mógłbym kiedyś przeoczyć jakiś import i w efekcie nie poprawić tych danych po raz kolejny.
Ale operator (Geosystem) jest tylko właścicielm serwera, i wprowadzającym dane na początek. Właścicielem danych i edytorem jest dana gmina / miasto. Więc tam powinieneś kierować uwagi na temat konkretnych punktów. Ja czasem to robię, ale nie sprawdzam, czy to zrobili i z jakim opóźnieniem… Geosystem może (powinien) co najwyżej przekazac Twoje zgłoszenie do gminy.
Przyznaję, w gminie nie pytałem. Ale na stronie (w końcu) gminnej e-mapy jest przycisk [Zgłoś problem] - więc tą drogą zgłaszałem. Za każdym razem otrzymuję w takim razie na maila informację o przyjęciu zgłoszenia i prośbę o potwierdzenie przez klikniecie w link potwierdzający, że to ja zgłaszam. W mailu jest info, że zostanę poinformowany o podjętych działaniach - i na tyle. Pierwsze zgłoszenia zacząłem robić po imporcie punktów adresowych które na podstawie e-mapy zrobił Zibi. Zresztą w korespondencji, którą na tę okoliczność prowadziliśmy, zasugerował, że skoro jest taka możliwość - to należy z niej skorzystać w sytuacjach wątpliwych, albo ewidentnie błędnych. Więc korzystam. Zgłosiłem w ten sposób chyba 15 uwag i na żadną nie otrzymałem odpowiedzi. Zakładam, że w ten sposób wykonane zgłoszenie “co do danych” jest obsługiwane przez osobę upoważnioną w gminie. Natomiast nie mam pojęcia, jak wygląda ta sprawa od strony Geosystemu - kto i w jaki sposób przekazuje zgłoszenia. Na bieżąco śledzę informacje o nowych punktach adresowych i widzę, że sposób prowadzenia tej mapy jest dość “mało profesjonalny”. Np. ostatnio ktoś wprowadzając nowy punkt adresowy umieścił go w konturze budynku, który adres ma co najmniej od 100 lat co spowodowało przypisanie do obrysu nowego numeru a stary wyparował z mapy.
Co do opisu na wiki, to uwazam, ze narzedzie nie powinno dodawac do OSM tych trzech dodatkowych tagow, czyli: teryt:simc i teryt:sym_ul (atrybuty miejscowosci i ulicy) i ref:addr. Nie widze powodu by byly one na punktach, a proces importu czy aktualizacji tak czy tak ma dostep do tych danych. Z czysto logicznego punktu widzenia tez uwazam ze powinno to byc np. addr:teryt:sym_ul bo wezel moze opisywac dowolne POI, ale ulica to tylko atrybut adresu.
Pomijajac ze 2m to dosyc malo (zaleznie od tego jaki use case ma to obsluzyc, bo czasem punkty trzeba przesunac o setki metrow), skrypt powinien poprawiac tag tylko wtedy kiedy w zrodle oryginalnego importu (jesli punkt jest z importu) nastapila zmiana z A na B, a w OSM tag jest nadal w wersji dokladnie A. Przy okazji jest to duzo prostsze niz heurystyki oparte na porownywaniu odleglosci do jakiejs stalej, wielkosci liter, itp.
Proces import u ma dostęp tylko do danych, które są w źródle importu. Nie ma dostępu do tych atrybutów, które zostały były w źródle importu na czas wprowadzania danych do OSM.
Bez ref:addr dla GUGiK nie jestem w stanie wyliczyć różnicy - co zmieniło się w źródle bez bazy danych, która będzie zawierała meta-dane wspomagające import. Ale gdyby posługiwać się taką bazą, to baza OSM przestałaby być samodzielną bazą w zakresie punktów adresowych. Gdyby ktoś chciał ją zforkować, to musiałby ją sforkować razem z tą pomocniczą bazą. No i ktoś musi tą bazę utrzymywać, backup’ować itp., w takim samym harmonogramie, jak bazę OSM. Dla iMPA nie wiemy nawet jakie zostały (i czy w ogóle) zmiany, więc chociaż wiemy o którym punkcie mowa.
Niezależnie od tego - ponieważ dla aktualnie wprowadzonych danych w OSM nie wiemy jaki był stan punktu w momencie importu, heurystyki i tak są konieczne, by doprowadzić do stanu, gdy aktualizacje możemy wykonywać w miarę automatycznie.
No ale do czego innego może się odnosić teryt:sym_ul niż do symbolu ulicy (który albo będzie w addr:street albo w name dla highway=)? Tak samo teryt:simc - z tym że simc występuje jako identyfikator dla name na place=.
EDIT: No i jeszcze pozostaje kwestia, że jak ktoś przeniesie adres na obrys budynku lub skasuje adres - to i tak potrzebna jest heurystyka zasilana zmianami w planet.osm, by takie zmiany śledzić w “pomocniczej” bazie.
Geo-System zaprasza do korzystania z tego przycisku, z tego co pamiętam, to pierwsza linia obsługi jest w GeoSystem, później te zgłoszenia przekazują do Gminy, jeżeli jest wymagana zmiana w ewidencji. Natomiast z realizacją to wspominali, że bywa różnie
Jesli nie ma, to jest to wybor importujacego czy tez autora skryptu, nie wina OSM.
Nie wiemy? Tzn. moze nie wiemy ale mozemy dosyc latwo te informacje wygenerowac porownujac stan oryginalny i aktualny. Stan oryginalny mozna otrzymac od osoby, ktora pobierala dany obszar, w wiekszosci przypadkow sa to osoby, z ktorymi masz czesto kontakt.
Nie wiem jaki jest aktualny stan API bazy impa, ale prawdopodbnie mozna ten stan tez pobrac biorac date importu.
I jesli chodzi o forkowanie, to ostatecznie importy to tylko stan tymczasowy – nie mozna liczyc na zewnetrzne bazy danych, od dlugoterminowego prowadzena bazy mamy spolecznosc dzialajaca w terenie.
W miare automatycznie czyli obecnie istniejace 5 z hakiem miliona punktow tez mialyby dostac te tagi?
Jesli tak, to wbrew temu, co pisales wczesniej wartosci tych tagow mozna wyliczyc (chyba ze ktos mialby je recznie dodawac?) i nie sa potrzebne w bazie.
I jeszcze wracam do kwestii czy te 2m to nie za malo – mysle, ze sensowniejsze jest sprawdzanie w calej gminie.
Nie wiem – dlatego wlasnie tag powinien byc nazwany od tego do czego sie odnosi
Do czego innego niz do teryt moze odnosic sie sym_ul? A jednak ma odpowiedni prefix
EDIT: chodzi mi tez o to, ze nadawnie jakiegos identyfikatora terytowego czemus co nie ma takiego identyfikatora to praktycznie wprowadzanie bledow.
Może osoba, która robiła ma stan oryginalny, może nie. Może dostaniesz od niej odpowiedź w ciągu 10 minut, może w ciągu 10 dni. Takie rozwiązanie słabo się automatyzuje i słabo się skaluje. Celem dla mnie jest to, by skrypt działał CIĄGLE i AUTOMATYCZNIE. Jakiś lokalny mapowicz (nie koniecznie mistrz importów) tylko wyciąga różnice i wprowadza do OSM, ale nie musi wykonywać całej tej pracy. Dzięki temu też - jesteśmy w stanie powiedzieć, ile adresów w danym miejscu brakuje i potrzebuje uwagi, bo inaczej - ciągle byśmy rozbijali się o problem - że automat nie ma źródła, z którego został wykonany import.
A po co mamy duplikować robotę, którą robią gminy? Ja wolę wykorzystać społeczność do tego, by poprawiała nam jakość danych, tam gdzie dane w źródle są błędne, albo do mapowania takich rzeczy, do których nie ma źródeł, niż angażować tabun ludzi do tego, by patrzyli na adresy. Więc dla mnie to stan końcowy, a nie tymczasowy.
Też miałoby dostać te tagi. W miarę automatycznie - czyli z wykorzystaniem tej heurystyki oraz pracy ludzkiej - podczas wykonywania importu, oraz późniejszej pracy innych mapowiczów. Pewnie to wysiłek rzędu 2000h. Moim zdaniem - warto to zrobić raz, niż palić te 2000h rok-rocznie.
2m dotyczy sprawdzenia tylko - czy jest jakiś punkt adresowy w tym miejscu. Adresu o takiej samej postaci szukam w całym importowanym obszarze.
No to wtedy może już zrobić tak: addr:street:ref:teryt i addr:city:ref:teryt / addr:place:ref:teryt - to nam wskaże jednoznacznie - czego identyfikator tu się znajduje. Natomiast taki schemat tagowania nie sprawdzi się w przypadku tagowania highway czy place.
Z SIMC się nie upieram, natomiast moim zdaniem - to dodatkowa informacja którą można wykorzystać przy generowaniu “mrówek” oraz weryfikacji danych (np. zduplikowanych adresów w gminie), SYM_UL moim zdaniem sporo ułatwia - i pozwala na łatwe zaangażowanie całej społeczności w budowanie standardu nazewnictwa w OSM, a przy ref:addr będę się upierał - jak dla mnie - to jest to w stanie oszczędzić szalenie dużo pracy.
Generalnie - w tej chwili skrypt działa całkiem nieźle i bez ref:addr sporo jest w stanie zrobić, chociaż wymaga trochę czasu na każdą gminę (15 minut do 1h). Wydaje mi się - że zastosowanie ref:addr pozwoliło by na to, by temat kończyć w 3-5 minut. A jak spojrzałem na próbę zmierzenia się z Warszawą - to jak na razie to mnie przerosło, bo dostałem chyba z 10k punktów do przejrzenia. Zresztą - w GUGiK jest o wiele więcej błędów które poprawiamy, niż w iMPA, co w przypadku - gdy kasujemy adresy - niestety nie przenosi się do kolejnego uruchomienia.
jak należy poprawić w OSM błędnie zaimportowany adres, aby skrypt przy kolejnym przeglądaniu nie poprawił go spowrotem na adres błędny?
Czy skrypt może (przy okazji) wykasować adresy, które ktoś wprowadził do OSM, a których nie ma w imporcie?
Czy może dodać z powrotem adresy, których już w OSM nie ma (bo np. wybudowano tam dwupasmową drogę na miejsce jednopasmowej i część adresów nie jest już do niczego potrzebna)?
I najważniejsze:
Czy kolejne “importy” wszystkich adresów są potrzebne? Czy nie lepiej byłoby wziąć stare źródło importu, porównać z nowym źródłem i dodać tylko nowe adresy, a reszty nie ruszać? Ja wiem, że fajnie się importuje różne rzeczy, ale wartość danych OSM polega według mnie głównie na tym, że te dane są weryfikowane w terenie i dodawane/poprawiane przez społeczność - dzięki czemu są w miarę aktualne i zgodne z rzeczywistością bardziej, niż importowany materiał źródłowy. Jeszcze bardziej optymalnie byłoby dodać do bazy OSM tylko te z nowych adresów, których tam nie ma, generując ewentualnie coś w rodzaju mrówek do sprawdzenia dla adresów, które są położone w OSM niezgodnie z położeniem w imporcie lub w OSM ich nie ma (dając możliwość usunięcia mrówek podobnie do zaznaczania błędów keepright jako fałszywe błędy).
A odnośnie czasu trwania importu - nowe mapy dla nawigacji generowane są średnio raz na miesiąc - czy częstsza automatyczna aktualizacja adresów jest potrzebna (czy ma sens)?
Jeżeli będziemy korzystać z ref:addr, to po prostu import go nie dotknie, chyba że wystąpiła zmiana w źródle (dla EMUiA GUGiKoweg)
Jak na razie oznacza takie adresy za pomocą fixme. Jak będziemy korzystać z ref:addr, to będzie mógł usuwać z automatu. Natomiast adresy wprowadzone z palucha, bez ref, moim zdaniem - wymagają za każdym razem ręcznego sprawdzenia.
Jeżeli mówimy o usunięcu adresów w OSM, to jeżeli zastosujemy protokół, że zamiast usuwać punkty, zostawimy je z ref:addr i source:addr, to wtedy skrypt nie doda ponownie tych punktów. W tej chwili - nie ma możliwości wykrycia takiej sytuacji.
No staram się zachować za pomocą tego skryptu dokładnie takie zachowanie. Zauważ że:
źródła importów nie będą przechowywać stanu importów danych do OSM
dane z importów powinny być do wprowadzania również przez typowych mapowiczów. Patrz casus Skarżyska Kamiennej - tam lokalny mapowicz wprowadza adresy, które pojawiają się w EMUiA GUGiK, ale nie ma pewności, czy dodał wszystkie - i temu użytkownikowi chcę pomóc - powiedzieć mu, które adresy są jeszcze do dodania, usunięcia itp. Bez porównania całości danych, nie pomożemy mu. Poza tym - porównania całości pozwala wychwytywać wandalizmy, błędy w dodawaniu danych itp.
Ja mam nadzieję, że przy tym nowym sposobie, będziemy mieli aktualność średnio 6 miesięcy względem źródeł. W obecnym stanie, to jesteśmy w stanie utrzymać aktualność na poziomie 2 lat. To że skrypt będzie raz na dwa miesiące odwiedzał daną gminę, to jeszcze nie znaczy, że ktoś te dane wrzuci w OSM…
Pomysł ze skryptem jest dobry, IMHO całe zagadnienie trzeba rozbić na poszczególne przypadki użycia. Założenie jest takie, że dla każdego punktu przypisana jest dodatkowo urzędowa data wprowadzenia zmian.
Dla punktu z importu, w OSM znajduje się już punkt (lub obrys) o takim samym ref:addr. Jeżeli data modyfikacji punktu w OSM jest taka sama lub nowsza niż data urzędowa - ignorujemy wszelkie różnice. Jeżeli data urzędowa jest nowsza i występują zmiany (inny housenumber, kod pocztowy, różnica w położeniu większa niż X metrów) - generujemy komentarz fixme. Rozwiązuje nam to problem w którym punkt był już poprawiony przez mapowicza (np. przesunięty o kilkaset metrów) a importer dalej sypie błędami fixme.
Dla punktu z importu, w OSM nie ma takiego adresu z zadanym ref:addr. Dodajemy go do OSM, jako addr:street wpisując nazwę urzędową. Oczywiście nazwa urzędowa naprawdopodobniej będzie inna niż nazwa w OSM, ale to bardzo łatwo wychwycą mrówki - nowe adresy nie pojawiają się aż tak często, żeby przynajmniej na pierwszym etapie nie poprawiać tego ręcznie. Jeżeli chodzi o różnicę pomiędzy urzędową nazwą miejscowości a nazwą w OSM do jest to proste dopasowanie za pomocą teryt:simc.
Oczywiście te dwa punkty nie obejmują wszystkich przypadków, ale je można rozwiązać za pomocą cyklicznej walidacji bazy OSM, robionej przed importem. Walidacja ta wychwyci:
punkty adresowe bez ref:addr i teryt:simc - najprawdopodobniej dodane ręcznie przez użytkowników. W większości przypadków teryt i ref:addr można z automatu zaimportować z danych urzędowych (gdy przesunięcie jest mniejsze niz kilka m).
w OSM istnieje punkt adresowy i zadanym ref:addr, ale w danych urzędowych go nie ma - dodanie tagu fixme, bo najprawdopodobniej wypadł z ewidencji.
Co Wy na to? Upraszcza to sporo wiele rzeczy a rzadko pojawiające się zmiany, choć upierdliwe algorytmicznie można prosto rozwiązać raportowaniem dla użytkowników OSM.
Wygląda sensownie (z punktu widzenia kogoś, kto ręcznie zebrał adresy miejscowości w terenie i na tej podstawie dodał je do OSM i nie ma ochoty poprawiać błędów zrobionych potem przez automat ). Dodałbym jeszcze jedną rzecz to tego, która powinna pozwolić wyeliminować te sztuczne punkty - pozostałości po usuniętych adresach: ustalamy najmniejszą jednostkę administracyjną, która zawsze przetwarzana jest przez skrypt w całości - po zakończeniu działania skrypt dodaje w jej admin center tag z wartością daty ostatniej synchronizacji, a przy kolejnej poprawia tylko adresy z świeższą datą aktualizacji w importowanych źródłach. Jeśli skrypt zawsze będzie odpalany na tej samej maszynie, to daty takie można trzymać równolegle w lokalnej bazie danych - powinna być relatywnie mała (w porównaniu z ilością danych dla wszystkich adresów).
Na koniec pytanie: czy istnienie więcej niż jednego punktu z tym samym adresem jest błędne, czy nie? Pytam w kontekście POI z dodanymi danymi adresowymi (czyli czy dodanie tego samego adresu do kilku POI jest błędem, a jeśli tak, to jak należy to robić poprawnie)?
No dobrze, czyli problemem jest brak odpowiedniego API. Moge sie sprawie blizej przyjrzec i takie API ustawic (na za jakis czas), ktos kto bedzie chcial sprawdzic zmiany miedzy stanem z ostatniego importu a aktualnym pobierze sobie z tego API wersje wersje poprzednia i skryptami wyciagnie roznice, a potem ew. skryptami nalozy te roznice na OSM.
Mysle, ze propozycja ktora jest na wiki bardzo komplikuje sprawe z powodu czegos wzglednie blahego.
Pod wieloma wzgledami to ma sens, ale mysle ze to nie jest dobre forum do dyskutowania zmian zalozen projektu OSM, proponuje listy talk i imports.
/o\
Ulatwia mysle, ze tyle, co zrobienie prostej biblioteki, ktora dla danego adresu sprawdzi sym_ul na odpowiedniej ulicy. Powtarzaja sie dosyc czesto argumenty za kopiowaniem atrybutow dotyczacych wszystkich obiektow w danym obszarze na wszystkie punkty ktore w nim sa, po to by ulatwic postprocessing, i to jest jeden z tych argumentow.
Ale z tym prefiksem addr: dla teryt:sym_ul chodzilo mi jedynie o nazwe tagu. Ulica, ktora ma nadany kod SYM_UL, nie moze miec takiego samego tagu, jak obiekt ktory nie ma nadanego tego numeru. Tak samo punktom przy danej ulicy ni nadajemy name=Marszałkowska tylko addr:street, po prostu jest to nie logiczne i wprowadza dosyc spory blad do bazy.
Rozwiązanie genialne w swej prostocie. W tej chwili i tak importy są robione na poziomie gminy. Widzę tylko dwa problemy: zmienność granic w czasie oraz mała dokładność obecnie wyrysowanych granic
Pamiętaj że chodzi o API między mało doświadczonym użytkownikiem a resztą społeczności. Typowy przypadek użycia który rozważam to:
Użytkownik wchodzi na stronę, znajduje tam informacje o tym, że baza referencyjna zawiera 10 więcej adresów niż OSM
Otwiera plik OSM z tymi 10 adresami
Weryfikuje te dane
Robi upload do OSM.
Dopiero gdy zrobi upload, możesz wziąć bazę jakiej użyłeś do wygenerowania tego pliku jako bazę dla kolejnego użytkownika.
Moje rozwiązanie jest o tyle proste, że za pomocą obecnie dostępnych narzędzi definiujemy protokół komunikacji i użytkownik o niczym nie musi pamiętać. I to jest najważniejsze.
Po drugie tez, moim skromnym zdaniem, jak importujemy jakieś dane, to przyzwoitość nakazuje, by razem z tymi danymi wrzucić klucz główny z bazy źródłowej. Ale dyskusje o tym, tak jak piszesz, wrzucę na talk i imports.
Rozumiem to. To API ktore zaproponowalem mogloby byc tylko zrodlem danych dla takiego interfejsu, nie zamniennikiem. Ale nie wyklucza tez, ze ktos z linii komend bedzie u siebie odpalal te same procesy, ktorych uzywa interfejs webowy.
Teoretycznie tak, ale w praktyce (importy dyskutowane na imports@ a przede wszystkim import TIGER) okzauje sie, ze nikt z tego nigdy nie skorzystal, a tagi strasza mapowiczow ktorzy nie wiedza co one oznaczaja, oraz edytory (w przypadku drog na przyklad, w efekcie laczenia pojawiaja sie tagi typu id=543233;2544538;298455;328239;10092 a pozniej nawet ciagi z powtorzeniami). Po drugie czesto taki identyfikator to po prostu szum, bo w oryginalnej bazie przy roznych operacjach ID sie regeneruja.
Ktos stwierdzil czy te klucze w bazie GUGiKu sa jakos skorelowane z danymi poza CODGiK, np. w iMPA? Przy okazji, czy to konto, ktore dostalismy testowo od GeoSystem otwiera dostep do jakichs dodatkowych atrybutow?
). Dodałbym jeszcze jedną rzecz to tego, która powinna pozwolić wyeliminować te sztuczne punkty - pozostałości po usuniętych adresach: ustalamy najmniejszą jednostkę administracyjną, która zawsze przetwarzana jest przez skrypt w całości - po zakończeniu działania skrypt dodaje w jej admin center tag z wartością daty ostatniej synchronizacji, a przy kolejnej poprawia tylko adresy z świeższą datą aktualizacji w importowanych źródłach. Jeśli skrypt zawsze będzie odpalany na tej samej maszynie, to daty takie można trzymać równolegle w lokalnej bazie danych - powinna być relatywnie mała (w porównaniu z ilością danych dla wszystkich adresów).