Prośba o import adresów

Niestety Nominatim ma tendencję do „gubienia się” przy obiektach położonych blisko granicy relacji co wynika z aproksymacji jaką Nominatim stosuje do określania adresów.
Tutaj przykłady ze Szczecina które mimo zawierania się w obrębie relacji są przez Nominatim przyporządkowywane do innych miejscowości.

Koniec końców Nominatim daje rady je jednak odnaleźć (choć np. Photon w przypadku pierwszych 2 adresów się poddaje) ale bez addr:city może IMHO powstać u użytkowników wątpliwość która miejscowość jest właściwa.
Inną kwestią są też nieprawidłowo wyrysowane granice. Często spotykam niestety sytuacje, w których nawet gminy są wyrysowane (miejscami sporo) niedokładnie i „łapią” miejscowości z ościennych gmin.
Dlatego uważam, że addr:city/addr:place nawet w przypadku wyrysowanych granic nie jest redundantne i zawsze je uzupełniam jeśli są takie braki.

+1

Wychodzi na to, że najlepszym rozwiązaniem byłoby dodanie addr:city do adresów w granicach Szczecina lub zignorowanie tego tagu przy weryfikacji braków w adresacji.

Biorąc pod uwagę wcześniejsze argumenty, przychylam się jednak do dodania tagów addr:city. Przy okazji można by uzupełnić kody pocztowe, aby była przy tym jeszcze jakaś wartość dodana :slight_smile: Nie jestem specem od masowych edycji, więc musiałby to zrobić ktoś inny.

A zdarza się, że ulica lub adres należą do miejscowości B, a leżą w miejscowości A. Dlatego moim zdaniem trzeba podawać addr:city lub addr:place w każdym adresie.

+2

addr:city można po prostu dodać. Z addr:postcode już nie jest tak łatwo.

Było dobrze, przed wprowadzeniem zmian na https://budynki.openstreetmap.org.pl/ miałem zaimportowane wszystkie adresy miasteczka, okolicy i kilku innych pobliskich miast. Teraz w okolicy dziesiątki adresów, które już są w OSM.

Ale są w złych miejscach :slight_smile:

Przy okazji: dlaczego na https://budynki.openstreetmap.org.pl wszystkie numery mają zawsze duże litery, jak na tym obrazku? Tak jest w PRG?

No są trochę w złych miejscach, ale kto będzie teraz siedzieć i to sprawdzać. Wcześniej te dane były gotowe od razu do importu.

Na tym przecież polega import?
Jeśli takich adresów nie jest dużo np. 100-200 lub kilkaset, to można spokojnie je zaznaczyć i dodać do listy w JOSM-owym pluginie todo. Potem każdy odhaczyć.

Po co tak utrudniać życie? Było dobrze, to trzeba było popsuć…

Jak mogło być dobrze, skoro numer 72b jest pomiędzy dwoma budynkami bez adresów? Skąd użytkownik danych OSM ma wiedzieć, którego budynku on dotyczy?

Dodane:
https://www.openstreetmap.org/node/2934907502

Dodane2:
W tym mieście jest chaos adresowy, a nie “było dobrze”.

Przecież widać, że 72a jest z przodu to do budynku z przodu, a 72b za to za.

Tego nie widać, bo adres jest w odległości długości budynku. Na tej mapie nie widać gdzie jest “przód” budynku, chyba że doda się szczegóły takie jak wejście i ścieżki.
Jeśli budynek jest już wybudowany, to adres powinien być w obrębie tego budynku. Więc dobrze, że wyskoczyło dużo nowych adresów do dodania, bo można uzupełnić braki.

Przy przetwarzaniu PRG standaryzuję je do wielkiej litery. Adresy powinny być “case-insensitive” tj. nie powinno być dwóch adresów rozróżnianych wielkością liter, a duże litery po prostu lepiej wyglądają w numerze.
Jeżeli dobrze pamiętam rozporządzenie, które określa reguły nadawania numerów porządkowych mówi, że litery przy numerze powinny być duże, więc adresy w PRG, które mają małe litery są raczej zaszłościami historycznymi, błędami albo po prostu gminy ignorują rozporządzenie.

Jeżeli zmieniamy w OSM nazwy ulic w porównaniu do formy zawartej w TERYT, która jest najbliższa obowiązującemu stanowi prawnemu to z tym tym bardziej nie powinno być problemu moim zdaniem :slight_smile:

W sumie tak na szybko sprawdziłem to chyba tak wygląda stosunek liczby adresów z małymi lub dużymi literami w PRG:

male_litery | duze_litery | male_i_duze_litery | count
-----------±----------±------------------±----------
557 555 | 864 100 | 681 | 7 712 207

Zdecydowanie więcej tych z małymi literami niż się spodziewałem. No, ale mimo wszystko uważam, że lepiej je standaryzować do wielkiej litery.

Zmieniłem na 40 metrów w warunku. Dane dzisiaj wieczorem zaczną się przeładowywać jak co tydzień i w sobotę koło południa powinno być widać zmiany.

@tomczk: Może to Ci się przyda przy dopasowywaniu adresów.
https://github.com/RicoElectrico/mismatched_street_name_validator/blob/master/canonical_name.sql
(musisz odkomentować name = regexp_replace(name,stop_words,‘’,‘g’); - zakomentowałem to dla wersji “eksportowej” poza Polskę, bo każdy kraj może chcieć dać inne słowa do kasowania i lepiej nie dawać żadnych niż obecnych bez poprawy. Moja polska wersja ma/miała to odkomentowane. Trochę więcej kontekstu z przykładami jest w readme repozytorium.

Funkcja oczywiście nie będzie nieomylna, bo całkowicie ignoruje imię, ale do celów ukrywania adresów już istniejących w OSM będzie dobra.
Edit: Trzeba by jeszcze dodać odpowiednie skróty z kropką do powyższej funkcji.

Przykładowe miejsce, gdzie obecne dopasowanie niedomaga - ulica Śmidowicza w Gdyni:
https://budynki.openstreetmap.org.pl/#map=17.86/54.54295/18.540733

@maro21 tak, ale jak robiłem importy to po kilkadziesiąt adresów na raz, a teraz jak mam sprawdzać każdy adres dokładnie to zaimportuję kilkukrotnie tego mniej. Może ktoś i mnie skrytykuje, ale uważam, że lepiej dodać 50 nowych adresów, których nie było w OSM, niż poprawić 10, bo są o 15m dalej niż dom.

Nie było dobrze, takie miejsca jak twój przykład są wadliwie zmapowane i do poprawy.

Choć jeśli to możliwe - może da się udostępnić obie wersje?

I tu jest zasadnicze clou dyskusji, która nam się ostatnio w tym wątku zrodziła – gdzie położyć priorytet w adresacji w polskim OSM ? Czy w sytuacji kiedy mamy jeszcze ponad 400k ewidentnie ewidentnych braków adresowych kłaść nacisk wpierw na ich uzupełnianie czy wyłapywać może nawet pojedyncze braki/niedopasowania ale kosztem zwiększenia nakładu pracy przy obróbce wprowadzanych danych ? Dziś powoli kończę aktualizację Poznania zapuszczoną po obniżeniu parametru odległości do punktu PRG. Istotnie – w kilku miejscach dotychczas wprowadzony adres był sporo przestrzelony i to udało się wyłapać, ale z drugiej strony blisko 30% meldowanych braków było fałszywymi alarmami (głównie różnice w nazwie św. => święty + trafianie w duże budynki), zatem mniej więcej o tyle wzrósł też nakład pracy.

Takich miejsc jest mnóstwo, bo niestety takiej jakości dane udostępniają gminy. Nawet w tych które prowadzą adresację w iMPA średnio około 1/5 nie trafia w budynki. Choć czasami to jest najmniejszy problem…
Z ciekawości wpisz sobie w e-mapa.net „Czułówek Oświęcimska 19” a potem kliknij funkcję „informacje o obiekcie: i kliknij ponownie w ten adres. Teraz okaże się że jest to Nowa Wieś Szlachecka Oświęcimska 19. Takich punktów jest wzdłuż tej ulicy 13. Podobnie jest z ulicą Galicyjską, gdzie według gminy adresy są jednocześnie w 2 miejscowościach naraz. Sprawę zgłosiłem do poprawy w maju br. bezpośrednio do osoby prowadzącej adresację. Jak widać pół roku to za mało żeby uporządkować 20 punktów adresowych. A potem możesz dzięki takim pułapkom dostać taki pozytywny feedback za cały swój trud…

Numery powinny być case-insensitive przy sprawdzaniu, ale przy wyświetlaniu powinny być oryginalne.
Litery “I” oraz “O” wyglądają gorzej w numerze niż “i” “o”. (przykład - https://www.openstreetmap.org/node/7394883823 )

Rozporządzenie nie wspomina nic o wielkości liter.
Wrocław stosuje wyłącznie małe litery w adresach, i w takiej formie widnieją one też na tabliczkach na budynkach.
Tak, jest dużo zaszłości historycznych - np. w niektórych miejscowościach wciąż po wielkości literki w adresie można ustalić położenie budynku względem ulicy.
Jest to całkowicie zgodne z przepisami.

Problem jest, bo wprowadza to niespójności - tak jak we Wrocławiu, gdzie nowe adresy importowane ze strony budynki.openstreetmap.org.pl z dużymi literami odstają od reszty adresacji.

Ja też robiłem importy bez sprawdzania przed nimi, bo dochodziły tylko nowe adresy. Teraz się zdarza, że nowy adres wchodzi na budynek, który już ma adres, co wymaga ręcznej poprawy, ale to dobrze, bo to wyjdzie dokładności na dobre.

No tak, dokładniejsze, ale znacznie mniej adresów zaimportuje się w tym samym czasie. W OSM są duże braki adresów. Gorszym problemem dla użytkownika jest brak adresu, niż to, że jest 10m dalej niż budynek, bo z takiej odległości sobie bez problemu dostrzeże na domu jaki to jest numer.

Czyżby została dodana jakaś nowa baza adresów? Bo zauważyłem, że teraz pojawiły się adresy, które naprawdę w rzeczywistości istnieją, a w PRG ich nie było. Sprawdziłem czy te adresy są w OSM i ich nie ma, a robiłem na bieżąco aktualizacje z budynki.openstre…