{"slug": "satquery-al-building-a-conversational-system-for-satellite-image-analysis", "title": "SatQuery Al: Building a Conversational System for Satellite-Image Analysis", "summary": "A developer built SatQuery AI, a conversational system that lets users query satellite and Earth-observation imagery in natural language instead of translating questions into specialized geospatial operations. The architecture separates natural-language understanding from analytical execution, routing requests such as vegetation-change detection or building detection to an analysis pipeline that produces verifiable evidence before a language model explains and visualizes the result.", "body_md": "SatQuery AI: Building a Conversational System for Satellite-Image Analysis\n\nI built SatQuery AI around a simple idea: I wanted users to interact with satellite and Earth-observation imagery through natural language rather than having to translate every question into a sequence of specialized image-processing and geospatial operations.\n\nA user should be able to ask:\n\n“Where has vegetation decreased?”\n\nor:\n\n“What changed between these two satellite images?”\n\nor:\n\n“Detect buildings in this region.”\n\nBut building a system that answers these questions reliably is fundamentally different from building a chatbot.\n\nThe distinction I kept coming back to was:\n\nA language model can explain an answer, but the satellite-analysis pipeline has to provide the evidence.\n\nThat distinction shaped the architecture of SatQuery AI.\n\nFrom Questions to Evidence\n\nA conventional conversational AI system can take a question, generate an answer, and return it directly. That approach is not sufficient when the answer depends on information contained in an image.\n\nSuppose I ask:\n\n“Show me the areas where vegetation decreased between these images.”\n\nA language model can generate a plausible explanation of vegetation change. But generating a sentence is not the same as detecting vegetation change.\n\nFor SatQuery AI, the workflow is closer to:\n\nAsk → Understand → Analyze → Verify → Visualize → Explain\n\nThe natural-language layer first needs to understand what the user is asking. The system then needs to determine what type of Earth-observation analysis is appropriate and execute that analysis against the available imagery.\n\nDepending on the request, that could involve object detection, segmentation, change detection, image comparison, vegetation analysis, land-use and land-cover analysis, object counting, or other geospatial operations.\n\nThe important part is that the analytical pipeline produces an actual result.\n\nFor the vegetation example, that result might contain regions identified as changed, measurements associated with those regions, percentages, confidence information, or other relevant geospatial information.\n\nOnly after that evidence exists does the conversational layer have something meaningful to explain.\n\nSeparating Understanding from Execution\n\nOne architectural decision I found important was keeping natural-language understanding separate from analytical execution.\n\nConceptually, the system can be viewed as several layers:\n\nNatural-Language Query\n\n        ↓\n\nQuery Understanding\n\n        ↓\n\nAnalysis Planning\n\n        ↓\n\nAnalytical Execution\n\n        ↓\n\nEvidence / Results\n\n        ↓\n\nVisualization\n\n        ↓\n\nNatural-Language Explanation\n\nThe language model is therefore not treated as the source of truth for visual analysis.\n\nIts job is to understand the request and communicate the result. The specialized analytical pipeline is responsible for producing the underlying evidence.\n\nA simplified representation of the routing logic looks like this:\n\nquery = \"Show me the areas where vegetation decreased\"\n\nintent = understand_query(query)\n\nif intent.type == \"vegetation_change\":\n\n    result = run_change_analysis(\n\n        image_a,\n\n        image_b\n\n    )\n\nanswer = explain_result(result)\n\nThe actual implementation can become considerably more complex, but the separation is important. It prevents the conversational component from becoming responsible for calculations and visual conclusions it cannot independently establish.\n\nMaking the Result Visual\n\nAnother important part of the system is that the result should not end as text.\n\nIf an analysis identifies regions of vegetation change, those regions need to be represented on the imagery or map.\n\nConceptually:\n\nresult = analyze(images)\n\nvisual_layer = create_visualization(\n\n    image=images,\n\n    regions=result.regions\n\n)\n\nreturn {\n\n    \"evidence\": result,\n\n    \"visualization\": visual_layer\n\n}\n\nThis gives the user two complementary forms of information.\n\nThe visualization answers:\n\n“Where did this happen?”\n\nThe analytical result answers:\n\n“What did the system measure?”\n\nAnd the natural-language explanation answers:\n\n“What does this result mean?”\n\nKeeping these three responsibilities distinct makes the interaction easier to reason about.\n\nBefore and After: Turning a Query into an Analysis\n\nWithout this separation, a conversation might look like this:\n\nUser\n\nShow me the areas where vegetation decreased between these images.\n\nAI\n\nVegetation decreased in several areas between the two images.\n\nThat answer sounds reasonable, but it provides little evidence.\n\nWith the SatQuery approach, the interaction is intended to become:\n\nUser\n\nShow me the areas where vegetation decreased between these images.\n\nSystem\n\nIdentifies the request as a vegetation-change analysis.\n\nAnalysis pipeline\n\nProcesses the two images and identifies relevant regions.\n\nVisualization\n\nHighlights those regions on the satellite imagery.\n\nSystem\n\nReports the resulting measurements and relevant confidence information.\n\nAI\n\nExplains what the analysis found in natural language.\n\nThe difference is subtle from the user's perspective, but significant from an engineering perspective. The second workflow has an explicit analytical stage between the question and the answer.\n\nAdding Conversational Memory with Hindsight\n\nOnce the system can perform individual analyses, another problem appears: users naturally want to continue the conversation.\n\nFor example:\n\nUser\n\nShow me the areas where vegetation decreased between these images.\n\nAfter receiving the result, the user might ask:\n\nNow compare those regions with the previous analysis.\n\nThe second question depends on context from the first interaction.\n\nI integrated Hindsight as the agent-memory layer for this part of SatQuery AI. Hindsight is designed to provide persistent memory for AI agents, allowing useful information from previous interactions to remain available instead of treating every interaction as completely isolated.\n\nHindsight on GitHub�\n\nHindsight Documentation�\n\nVectorize — What is Agent Memory?�\n\nThe distinction I found useful is that memory should preserve context, while the analytical pipeline should preserve evidence.\n\nFor example, memory can help establish that “those regions” refers to regions identified during an earlier vegetation analysis. It does not mean that memory itself becomes the source of the satellite-analysis result.\n\nConceptually:\n\ncontext = hindsight.retrieve(query)\n\nanalysis_request = understand_query(\n\n    query=query,\n\n    context=context\n\n)\n\nresult = execute_analysis(analysis_request)\n\nhindsight.remember(\n\n    query=query,\n\n    result_context=result\n\n)\n\nThis makes the interaction conversational without collapsing the boundaries between memory, reasoning, and analysis.\n\nThe Architecture I Ended Up Thinking About\n\nI think about SatQuery AI as six cooperating components rather than one large AI system.", "url": "https://wpnews.pro/news/satquery-al-building-a-conversational-system-for-satellite-image-analysis", "canonical_source": "https://dev.to/shanmukhamanidhar/satquery-al-building-a-conversational-system-for-satellite-image-analysis-15be", "published_at": "2026-09-28 15:40:10+00:00", "updated_at": "2026-09-28 15:51:19.816723+00:00", "lang": "en", "topics": ["computer-vision", "natural-language-processing", "ai-agents", "ai-tools", "generative-ai"], "entities": ["SatQuery AI"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/satquery-al-building-a-conversational-system-for-satellite-image-analysis", "markdown": "https://wpnews.pro/news/satquery-al-building-a-conversational-system-for-satellite-image-analysis.md", "text": "https://wpnews.pro/news/satquery-al-building-a-conversational-system-for-satellite-image-analysis.txt", "jsonld": "https://wpnews.pro/news/satquery-al-building-a-conversational-system-for-satellite-image-analysis.jsonld"}}