Geokodowanie

Budżet: 5000 UAH Termin: 4 dni

Cześć. Zajmuję się geokodowaniem/odwróconym geokodowaniem, OSM (Nominatim) i Mapbox, a także normalnym "adminem" przez poligony (PostGIS / punkt-w-poligonie), przez co przestają się zdarzać "ucieczki" do innej dzielnicy/za miasto.

Zgodnie z Twoim opisem problem jest typowy: próbujesz uzyskać dzielnicę/miasto z odpowiedzi geokodera (lub odwróconego) — a to heurystyka, przez co 10–15% punktów zawsze będzie błędnych, szczególnie na granicach i przy niepełnych adresach. Uniwersalne rozwiązanie to podział zadań:

adres → współrzędna (geokodowanie do przodu),

współrzędna → miasto/dzielnica (ściśle według poligonów, punkt-w-poligonie), a nie "jak zwrócił geokoder". Aby ocenić zakres i zaproponować dokładne rozwiązanie, potrzebuję:

10–20 przykładów "ucieczkowych" obiektów: oryginalny adres/miasto + współrzędne, gdzie teraz stawia;

jakie miasta/kraje, i jakie dane na karcie są gwarantowane (miasto? dzielnica? kod pocztowy?);

gdzie przechowujesz dane i czym rysujesz mapę (PostGIS jest/nie ma, stos frontowy).

Po tym przedstawię plan prac w etapach i zrobię poprawkę, aby adres/miasto/dzielnica były określane maksymalnie stabilnie i reprodukowalnie, bez ręcznego rysowania dla każdego miasta. Rozwiń

Budżet: 5000 UAH Termin: 3 dni

Cześć!

Szczegółowo zapoznałam się z Twoim zadaniem. Problem jest znany — spotkałem się z podobnym podczas pracy z OSM Nominatim i Mapbox. Oto moja wizja:

Dlaczego obiekty "latają" na obce znaczniki:

Nominatim zwraca centroid najbliższego znalezionego obiektu, a nie dokładny adres. Jeśli adres nie jest znaleziony na poziomie budynku — "skacze" na środek ulicy, dzielnicy lub nawet miasta. To są Twoje 15% pomyłek.

Problem z piramidą geokodowania — klasyczny fallback budynek → ulica → dzielnica → miasto wymaga walidacji na każdym poziomie. Należy sprawdzać importance i class/type w odpowiedzi Nominatim, a nie po prostu brać pierwszy wynik.

Dzielnice bez polygonów — zgadzam się, rysowanie ręczne dla każdego miasta jest nierealne. Rozwiązanie: wykorzystać granice administracyjne z OSM (relation boundaries, admin_level=9-10) lub GeoJSON dzielnic z otwartych źródeł (data.gov.ua ma granice dla większości miast). To da sprawdzenie point-in-polygon bez pracy ręcznej.

Mój plan:

Audyt obecnego pipeline: zobaczę jak dokładnie przebiega fallback i gdzie traci się dokładność
Dodam walidację po boundingbox i type z Nominatim — odfiltrowuję "szerokie" wyniki
Podłączę reverse geocoding do krzyżowej weryfikacji (koordynaty → adres → porównanie z oryginałem)
Dla dzielnic — pobiorę granice OSM przez Overpass API lub gotowe GeoJSON, zrobię point-in-polygon
Ustawię confidence score: każdy wynik otrzyma ocenę dokładności, abyś widział gdzie jest 100% dopasowanie, a gdzie potrzebna jest ręczna weryfikacja
Wynik: 95-98% dokładności zamiast obecnych 85%.

Mam doświadczenie z Nominatim API, Mapbox Geocoding, Overpass API, Turf.js (operacje geoprzeszestrzenne), PostGIS.

Termin: 2-3 dni
Cena: 5000 zł

Jestem gotowa omówić szczegóły i przyjrzeć się obecnemu kodowi. Rozwiń

Budżet: 5000 UAH Termin: 3 dni

Witaj! Twój projekt wygląda bardzo interesująco. Jestem gotów rozpocząć pracę natychmiast i zapewnić wysoką jakość.

Budżet: 5000 UAH Termin: 2 dni

To typowa historia, gdy geokoder działa „po linii” bez sztywnych ograniczeń i bez weryfikacji według wielokątów. Aby ocenić zakres i terminy, potrzebne są szczegóły: Geografia i jakie dokładnie „dzielnice” (poziom). Format danych wejściowych: oddzielne pola lub jedna linia. Przykłady 5–10 problematycznych adresów + co obecnie zwracają Nominatim/Mapbox. Oczekiwany wynik: punkt, adres, dzielnica, miasto, dodatkowe pola. Ograniczenia dotyczące stosu i infrastruktury. Jeśli chcesz, przeprowadzę audyt obecnego pipeline'u i zaproponuję poprawkę z testami na twoim zestawie przypadków.