Hey there!! I’m Rupam Golui.. though most people online know me as Agasta and I honestly prefer that. I’m a 2nd year CS undergrad from Kolkata, India. Most of my time these days goes into open source and projects (GitHub: Itz-Agasta). I mostly work in Rust, Python, and TypeScript. Outside of code - I cook. Genuinely, not just survival cooking lol. I used to game a lot but somewhere along the way work took over and tbh I haven’t looked back. Also I love linux, currently running Arch (btw) and have been distro hopping since I was a kid… tried basically most of them, maybe move to nix next year. I rice my setup way more than I probably should, even participate in Reddit competitions for it. Could genuinely yap about this for hours. Yaa that’s mostly me, maybe someday I want to build a cool project people actually love enough that I can keep maintaining it full-time for years (hopefully).

Honestly I got here through a side project. Was building something with ocean data, needed maps, used Leaflet & Mapbox. But I got too curious about how all of it actually works behind the scenes - the data, the tools, the geocoding side of things. One thing led to another and I ended up deep in Nominatim’s codebase somehow. A few PRs later and here we are :)

---

Ok so - I got into GSoC 2026!

I’ll be working on native category support in OSM’s search engine Nominatim this summer, and I’m really excited about it.

Right now Nominatim classifies every place using a single OSM class/type pair - like amenity=restaurant. It’s simple and it works, but it has some real limitations:

• A hotel that also has a restaurant creates two separate rows instead of one - wasteful for tables that are already huge
• boundary=administrative can’t distinguish a country from a municipality - Nominatim currently hacks around this using admin_level checks scattered everywhere in the code
• There’s no way to search for “wheelchair-accessible cafe” or “vegan restaurant” - a single class/type just can’t express that

The plan is adding a proper categories column (ltree[] in PostgreSQL) to the core tables, so a hotel-restaurant just gets {osm.tourism.hotel, osm.amenity.restaurant} in one row. Hierarchical queries then just work - “find all amenities” matches everything under osm.amenity.* at once.

Proposed DB schema - categories[] column in placex/search_name replaces all place_classtype_* tables

A nice side effect: we can drop the place_classtype_* tables - a bunch of separately maintained materialized tables, and replace them with one indexed column. Cleaner database, simpler code.

Stretch goals include a YAML-driven category generator for richer tags like cuisine.italian or access.wheelchair.yes, and API-level include/exclude category filtering so users can do searches like:

/search?q=restaurant+kolkata&include=cuisine.indian&exclude=food.fast_food

---

Rough summer plan:

• Community bonding: Setting up a planet-scale db & benchmarking on it, finalizing design
• Weeks 1-4: Schema changes + Lua category generation
• Weeks 5-7: Search index rework, replacing classtype tables
• Week 8: Migration tooling for existing installs
• Weeks 9-12: Stretch goals, testing, review buffer

Full proposal here if you want the deep dive: Link

Progress Report: Thread

I’ll be posting updates in that thread throughout the summer. And if you use Nominatim and have thoughts on what category filtering would be useful for your workflows… seriously, drop them below. I’d love to hear it.

- Agasta