The interesting constraint is that it aims to use open data and avoid API keys where possible.

Why maps are hard for language models

Map questions sound simple:

• find coffee near me
• show quiet parks nearby
• route to a place with shade
• find restaurants within walking distance

But those questions mix language, location, distance, categories, freshness, and user context. A language model can understand the request, but it should not invent geography.

The system needs tools.

Open-data shape

The project uses sources such as OpenStreetMap, Nominatim, Overpass, Wikimedia REST, and related open endpoints. The map UI is built around Leaflet and React.

The model’s role is to translate intent into geospatial operations:

• what is the user looking for?
• what radius or location matters?
• is this a route, POI search, or environment query?
• what enrichment should be added?

The tools then fetch actual data.

Product boundary

The app should be honest about uncertainty. Open geospatial data is uneven. Names change, POI tags are inconsistent, and “quiet” or “hipster” are semantic hints rather than guaranteed database fields.

That means the UI should show results as interpreted matches, not absolute truth.

What I learned

Natural-language interfaces work best when they produce inspectable structured plans. If the app can show the interpreted action, it becomes much easier to debug:

• searched category
• center point
• radius
• data source
• filters
• enrichment steps

This is especially important for maps because wrong answers can look visually convincing.

Current status

map-ask is private and prototype-stage. It is safe to discuss as an architecture pattern: use an LLM for intent shaping, then rely on real geospatial tools for facts.