Geocoding

Budget: 5000 UAH Deadline: 4 days

Hello. I am working on geocoding/reverse geocoding, OSM (Nominatim), and Mapbox, as well as in a normal "admin panel" through polygons (PostGIS / point-in-polygon), which is why "shifts" to another area/out of town stop occurring.

According to your description, the problem is typical: you are trying to get the district/city from the geocoder's response (or reverse) — and this is heuristic, which is why 10-15% of points will always be incorrect, especially at borders and with incomplete addresses. The universal solution is to separate the tasks:

address → coordinates (forward geocoding),

coordinates → city/district (strictly by polygons, point-in-polygon), not "as returned by the geocoder." To assess the volume and propose an exact solution, I need:

10-20 examples of "departed" objects: original address/city + coordinates where it currently places them;

which cities/countries, and what data is guaranteed to be available for the card (city? district? postal code?);

where you store the data and what you use to draw the map (PostGIS available/not available, front-end stack).

After this, I will provide a work plan by stages and make a fix so that the address/city/district is determined as stably and reproducibly as possible, without manual drawing for each city. Expand

Budget: 5000 UAH Deadline: 3 days

Hello!

I have thoroughly reviewed your task. The problem is familiar — I have encountered something similar when working with OSM Nominatim and Mapbox. Here is my vision:

Why objects "fly" to foreign markers:

Nominatim returns the centroid of the nearest found object, not the exact address. If the address is not found at the house level — it "jumps" to the center of the street, district, or even city. This is your 15% errors.

The problem with the geocoding pyramid — the classic fallback house → street → district → city requires validation at each level. It is necessary to check the importance and class/type in the Nominatim response, rather than just taking the first result.

Districts without polygons — I agree, drawing manually for each city is unrealistic. Solution: use administrative boundaries from OSM (relation boundaries, admin_level=9-10) or GeoJSON districts from open sources (data.gov.ua has boundaries for most cities). This will provide point-in-polygon validation without manual work.

My plan:

Audit the current pipeline: I will look at how exactly the fallback works and where accuracy is lost.
I will add validation by bounding box and type from Nominatim — filtering out "broad" results.
I will connect reverse geocoding for cross-checking (coordinates → address → comparison with the original).
For districts — I will pull OSM boundaries through Overpass API or ready GeoJSON, and perform point-in-polygon.
I will set up a confidence score: each result will receive an accuracy rating, so you can see where there is a 100% match and where manual verification is needed.
Result: 95-98% accuracy instead of the current 85%.

I have experience with Nominatim API, Mapbox Geocoding, Overpass API, Turf.js (geospatial operations), PostGIS.

Deadline: 2-3 days
Price: 5000 UAH

I am ready to discuss the details and take a look at the current code. Expand

Budget: 5000 UAH Deadline: 3 days

Hello! Your project looks very interesting. I am ready to start working immediately and ensure high quality.

Budget: 5000 UAH Deadline: 2 days

This is a typical story where the geocoder works "by line" without strict limitations and without checking against polygons. To estimate the volume and timelines, details are needed: Geography and which specific "districts" (level). Input data format: separate fields or one line. Examples of 5–10 problematic addresses + what Nominatim/Mapbox currently returns. Expected output: point, address, district, city, additional fields. Limitations on stack and infrastructure. If you want, I can audit the current pipeline and suggest a fix with tests on your set of cases.