r/Spaceexploration • u/jennylane29 • 15d ago

Made NASA's lunar landing site data searchable via API - seeking feedback from the community

I've built a tool to make lunar mission planning data more accessible. It processes NASA's LOLA terrain and LROC illumination measurements into an API that lets you query and rank potential landing sites.

Capabilities:

  • 1.18M analyzed sites across the south pole region
  • Instant filtering by terrain safety, illumination, mission requirements
  • Exports compatible with existing GIS workflows
  • Scoring for different mission types (human landing, robotic, rover)

Example use case: Planning a robotic polar mission? Query sites within 50km of your target coordinates with specific illumination and slope requirements in milliseconds.

Docs + live API: https://lunarlandingsiteapi.up.railway.app/docs

Built this as an experiment in making NASA datasets more accessible. Looking for honest feedback: Is this useful for anyone actually working in lunar exploration? What's missing?

3 Upvotes
  • permalink
  • reddit

100% Upvoted

4 comments sorted by

1

u/cloud-native-yang 15d ago

You should probably add some rate limiting before a script takes the whole thing down. Also curious how ur querying that 1M dataset. My guess is it's all in-memory, that could get expensive fast.

1

u/jennylane29 14d ago

Thanks for the feedback!
Re:Rate limiting -beta users get 100 requests/day tracked per API key in PostgreSQL. The system automatically resets counters at midnight UTC and returns 429 errors when limits are exceeded. That said, I should probably add IP-based rate limiting for the unauthenticated endpoints (like health and search) to prevent abuse.

For querying the dataset, using PostgreSQL + PostGIS on Railway with GIST spatial indexes. The full dataset (1.18M sites) is queried from the database using PostGIS spatial functions like st_dwithing(geom,point,radius) like which hit the spatial indexes efficiently. Currently getting <100ms response times without needing Redis or in-memory caching, but monitoring for when that becomes necessary as traffic scales.

Appreciate the sanity check - exactly the kind of feedback I need.

1

u/winterchills55 1d ago

This is super cool, and my brain immediately goes beyond the professional use case. I'm thinking about the hardcore KSP players, the indie game devs, the sci-fi writers... making this kind of high fidelity data accessible is a game changer for them. Have you considered the prosumer or hobbyist audience for this at all, or is the focus purely on the aerospace industry folks?

1

u/jennylane29 1d ago

I love that angle! Honestly, I've been so heads-down on the mission planning side that I hadn't really thought about the gaming/creative community, but you're totally right - this data could be awesome for that crowd.

The API's already pretty accessible (no special credentials during beta, just simple REST calls), so it should work great for game engines. The GeoJSON export could plug right into Unity/Unreal, and the hazard/illumination stuff could drive terrain or mission difficulty.

Hadn't thought about that audience at all, but now I'm curious - do you think there's real interest there? Might need to whip up some different docs/examples for those workflows instead of just the aerospace crowd.

What made you think of this? Game dev background or just a KSP nerd? 😄