Jak zbudować bazę danych miejsc od zera: OpenStreetMap, Google Places i mieszkańcy

Większość projektów z mapą zaczyna się od pytania o wygląd pinezek. Prawdziwy problem leży gdzie indziej: skąd wziąć punkty, które mają się na tej mapie pojawić, i skąd wiedzieć, że każdy z nich stoi tam, gdzie obiecuje jego opis.

Ten tekst opisuje metodę na przykładzie Szachowej Mapy, projektu własnego, w którym w dziewięć dni powstała baza 1436 miejsc do gry w szachy w 415 miastach. Mechanizm jest identyczny, gdy zamiast stołów w parkach podstawisz punkty odbioru, oddziały, punkty serwisowe, obiekty noclegowe albo katalog dostawców.

Trzy źródła, które kłamią w różnych miejscach

Nie ma jednego pliku z odpowiedzią. Są trzy źródła, każde z inną wadą, i dopiero razem dają zbiór, który się broni.

Dane otwarte to szkielet. W OpenStreetMap można zapytać o obiekty konkretnego typu w granicach obszaru administracyjnego, przez Overpass API, bez opłat i bez limitów komercyjnych. Zaleta: pokrycie jest ogromne, a dane mają identyfikatory, do których można wracać. Wada: pokrycie jest nierówne w sposób, którego nie widać, dopóki się go nie sprawdzi. W opisywanym projekcie w jednej dzielnicy nie było praktycznie żadnego obiektu szukanego typu, a mieszkańcy wskazali kilkanaście realnych punktów. Dane otwarte nie mówią „tutaj nic nie ma”, tylko „tutaj nikt jeszcze nie mapował”.

Komercyjny indeks miejsc, w tym przypadku Google Places, widzi świat inaczej. Zna obiekty nieobecne w danych otwartych i, co ważniejsze, pozwala zweryfikować to, co już mamy. Skan wyszukiwania tekstowego zwrócił wtedy zestaw punktów, z których większość pokrywała się z naszymi co do kilku metrów. To była walidacja pinezek, nie tylko nowe rekordy. Kilka pozycji było zupełnie nowych. Zależność działa w obie strony, więc oba źródła zostają w obiegu na stałe.

Ludzie to źródło najdroższe w obsłudze i najlepsze jakościowo. Tylko człowiek wie, że stół postawiono w zeszłym roku, że w lokalu naprawdę leży komplet i że plac zabaw „za bazarkiem” to ten drugi, nie ten pierwszy. W projekcie zgłoszenia przyszły z komentarzy pod postami w grupach dzielnicowych, z formularza na stronie, z wiadomości od właścicieli lokali oraz z urzędu dzielnicy, który pod postem podał trzy filie biblioteki. Jedna z osób pojechała na miejsce i naliczyła sześć szachownic tam, gdzie dane publiczne widziały zwykłe stoły piknikowe.

Pobranie danych to najprostszy etap

Zapytanie do API zajmuje popołudnie. Doprowadzenie odpowiedzi do stanu, w którym można ją pokazać publicznie, zajmuje dni. Poniżej cztery problemy, które w tym projekcie kosztowały najwięcej czasu, uszeregowane od najkosztowniejszego.

1. Rekordy bez nazwy i bez adresu

Import z danych otwartych dał 825 rekordów, czyli 68 procent całej bazy, o nazwach w rodzaju „Kraków: stoliki szachowe, punkt 5”. Żaden z tych opisów nie mówił, gdzie punkt się znajduje. Z punktu widzenia użytkownika taki rekord jest bezwartościowy: widać pinezkę, ale nie da się do niej dojść ani jej opisać znajomemu.

Naprawa polegała na geokodowaniu odwrotnym, czyli zamianie współrzędnych na adres. Zamiast numeru punktu wchodzi dzielnica i ulica: „Podgórze Duchackie, ul. Edwarda Heila”. Rekordów pozbawionych jakiejkolwiek wskazówki dojścia zostało 38 zamiast 533, a resztę stanowią małe miejscowości, w których geokoder nie zna ani ulicy, ani osiedla.

Dwie rzeczy, o których warto wiedzieć przed uruchomieniem takiego skryptu. Po pierwsze, wyniki geokodowania trzeba zamrozić w pliku i traktować jak dane, a nie odpytywać usługę przy każdym budowaniu strony. Po drugie, zmiana nazwy zmienia adres podstrony, jeśli budujesz podstronę per rekord. Tutaj było to bezpieczne, bo domena miała kilka dni i nie była zaindeksowana. Przy działającym serwisie taka operacja wymaga przekierowań 301, inaczej kasujesz sobie widoczność, którą właśnie zbudowałeś.

2. Duplikaty, których nie widać

Odsiewanie duplikatów po podobieństwie nazwy wygląda na rozsądne, dopóki nazwy nie pochodzą z geokodowania. Po nadaniu nazw z ulic dwa osobne stoły oddalone o 103 metry dostały nazwy różniące się tylko dopiskiem z numerem. Reguła uznała je za ten sam obiekt i jeden z nich zniknął z mapy. Wyszło to przypadkiem, bo w poście podaliśmy liczbę punktów w mieście, a mapa pokazywała o jeden mniej.

Reguła po poprawce łączy trzy warunki zamiast jednego: dwa obiekty mające osobne identyfikatory w źródle i oddalone od siebie o co najmniej 30 metrów są traktowane jako dwa różne miejsca. Poniżej tego progu scalanie zostaje, bo ten sam obiekt bywa zmapowany raz jako punkt, raz jako obszar. Poprawka odzyskała sześć realnych punktów.

Duplikat potrafi też przyjść z drugiej strony, przy ręcznym uzupełnianiu pól. Ten sam ośrodek kultury siedział w bazie dwa razy pod różnymi nazwami, oba wpisy podawały ten sam adres, a dzieliło je 317 metrów, więc żadna automatyczna reguła ich nie złapała. Rozstrzygnęło geokodowanie: jeden wpis leżał metr od realnego adresu, drugi miał współrzędne zaokrąglone do trzech miejsc po przecinku.

3. Rekordy, które opisują co innego, niż pokazują

Współrzędne mieszczące się w granicach kraju i poprawny format nie mówią nic o tym, czy punkt stoi tam, gdzie obiecuje jego opis. Każdy nowy rekord przechodzi więc trzy kontrole:

1. Geokodowanie odwrotne współrzędnych i porównanie miasta oraz ulicy z treścią opisu.
2. Geokodowanie adresu z opisu w drugą stronę i pomiar odległości od pinezki.
3. Odległość do najbliższego istniejącego punktu, żeby wychwycić powtórki.

Ta procedura wyłapała między innymi lokal, który w nazwie miał adres przy głównej alei, a stał 339 metrów dalej, oraz szkołę opisaną ulicą, przy której nie stoi. Osobna pułapka to geokoder trafiający w miejscowość o tej samej nazwie: biblioteka z Krosna na Podkarpaciu została wskazana w Krośnie Odrzańskim, 536 kilometrów dalej. Rekord źródłowy był poprawny, zły był geokod. Od tego czasu generator ma bezpiecznik na wielkość obszaru, bo obszar wielkości pół kraju to sygnał, że dopasowanie jest przypadkowe.

4. Pola, których lepiej nie zgadywać

Przy danych strukturalnych dla wyszukiwarki łatwo wpaść w pokusę wypełnienia wszystkich pól. W tym projekcie każda podstrona miejsca podawała przez pewien czas jedno miasto, wpisane na sztywno, więc Otwock przedstawiał się Google jako Warszawa. Ta sama rodzina błędu wróciła przy województwie: domyślna wartość była prawdziwa dla wszystkich rekordów w dniu, w którym powstała, i przestałaby być prawdziwa przy pierwszym punkcie spoza regionu.

Reguła, która została: przy nieznanej wartości pole nie powstaje. Puste pole jest gorsze wizualnie i lepsze merytorycznie od pola nieprawdziwego, bo dane strukturalne czyta maszyna, która nie ma jak zweryfikować, czy zgadywałeś.

Zasady wpisu, spisane zanim baza urośnie

Przy zbiorze budowanym ze zgłoszeń najszybciej psuje się nie jakość danych, tylko wiarygodność. Wystarczy, że wśród punktów pojawi się kilka wpisów wyglądających na reklamę, i czytelnik zaczyna podejrzewać o to wszystkie pozostałe.

Trzy decyzje, które warto podjąć na starcie:

• Co kwalifikuje się do wpisu. W tym projekcie reguła nie brzmi „komercyjne kontra darmowe”, tylko: czy miejsce sprzedaje naukę, czy wpuszcza do gry. Kluby, biblioteki i domy kultury zostają, komercyjne szkoły wchodzą wyłącznie jako oznaczony partner.
• Jak oznaczane są wpisy płatne. Osobny kolor i oznaczenie linku jako sponsorowanego. Płatny link bez oznaczenia to ryzyko kary od Google, także dla firmy, która za niego zapłaciła.
• Jaki jest próg wiarygodności zgłoszenia. Tutaj brzmi on: zgłoszenie mieszkańca wystarcza, jeśli da się ustalić lokalizację. Pytamy wyłącznie o to, gdzie dokładnie punkt się znajduje, nigdy o to, czy zgłaszający na pewno widział to, co opisuje.

Warto też z góry przyjąć, że rozważana bramka jakościowa bywa gorsza od filtra. W tym projekcie rozważaliśmy regułę „pełne wyposażenie na miejscu albo nie ma wpisu”. Policzenie zbioru pokazało, że skasowałaby ona większość mapy, bo na dworze nikt nie zostawia wyposażenia. Zamiast kasować cudze zgłoszenia weszły trzy przyciski nad mapą, które pokazują tę samą informację i niczego nie usuwają.

Co z tego wynika, jeśli budujesz katalog dla firmy

Podmień kategorię, a metoda zostaje ta sama:

• Sieć oddziałów albo punktów odbioru. Dane z własnego systemu, uzupełnione o geokodowanie, żeby każdy adres miał współrzędne, i o kontrolę, czy pinezka nie stoi w polu obok.
• Katalog obiektów noclegowych albo usługowych. Import ze źródeł zewnętrznych plus formularz zgłoszeniowy dla właścicieli, z moderacją zanim wpis stanie się publiczny.
• Baza punktów serwisowych albo partnerów handlowych. Osobna podstrona każdej lokalizacji łapie długi ogon zapytań lokalnych, których strona główna nigdy nie złapie.

W każdym z tych przypadków największą pozycją w budżecie nie jest mapa ani nawet integracja, tylko doprowadzenie danych do porządku i utrzymanie ich w porządku później. Warto to wiedzieć przed podpisaniem umowy, a nie w połowie wdrożenia.

Często zadawane pytania

Skąd wziąć dane do mapy punktów, jeśli nie ma gotowej bazy?

Z trzech źródeł naraz. Dane otwarte dają szkielet i są darmowe. Komercyjny indeks miejsc zna obiekty, których w danych otwartych nie ma, i pozwala zweryfikować współrzędne tych, które już masz. Trzecie źródło to ludzie, którzy dane miejsce znają. Żadne z tych źródeł nie wystarcza samo, bo każde pomija co innego.

Czym jest geokodowanie odwrotne i po co się go używa?

To zamiana współrzędnych na adres. Służy do dwóch rzeczy: do uzupełnienia nazw i opisów rekordów, które przyszły z importu bez adresu, oraz do sprawdzenia, czy punkt leży w mieście i przy ulicy, o których mówi opis. To najtańszy sposób na wyłapanie rekordu wstawionego w złe miejsce.

Jak odsiewać duplikaty w bazie miejsc?

Nie samą nazwą. Reguła oparta na podobieństwie nazw kasuje realne, osobne obiekty, gdy nazwy pochodzą z geokodowania i brzmią podobnie. Bezpieczniejszy warunek łączy identyfikator w źródle, odległość i podobieństwo nazwy. Dwa obiekty z osobnymi identyfikatorami oddalone o kilkadziesiąt metrów to zwykle dwa różne miejsca.

Czy dane z OpenStreetMap można wykorzystać komercyjnie?

Tak, na warunkach licencji ODbL, która wymaga podania źródła i zachowania licencji dla baz pochodnych. Dane z komercyjnych API rządzą się osobnymi zasadami, opisanymi w regulaminie dostawcy, w tym zasadami przechowywania. Licencję każdego źródła trzeba sprawdzić z osobna, zanim baza stanie się publiczna.

Ile trwa zbudowanie takiej bazy?

Pobranie danych to godziny. Doprowadzenie ich do publikacji to dni albo tygodnie, zależnie od tego, jak brudne jest źródło. W opisywanym projekcie największą pojedynczą pozycją było nadanie sensownych nazw 825 rekordom, które przyszły z importu jako kolejne numerowane punkty.