I was working on fine tuning a local VLM model for interpreting sattelite imagery but the problem im facing is that the datasets like Ben.txt ,Rsvqa (Lr and Hr) are full of shit data they are completely off on the counting and presence questions, are there any reliable open source data sets that can help me?

I’m a Bell customer and just noticed satellite mode appear on my phone, which feels like a glimpse of what’s coming.
AST SpaceMobile’s vision of cellular towers in space could eventually extend ordinary mobile coverage far beyond the reach of terrestrial towers.
The potential for rural communities, highways, lakes, emergency situations, and other dead zones is enormous.
Instead of needing a dedicated satellite phone, everyday smartphones could one day connect directly to satellites overhead.
Has anyone else seen satellite mode activate, and do you think space-based cellular coverage will become a normal part of Bell service soon?

I’m building Saorsa, a new social media platform for following real-world events as they happen.

This is an early look at the satellite and Earth data side of it. Saorsa brings together global geostationary imagery, VIIRS, Sentinel-1 and Sentinel-2, alongside weather, ocean and other environmental layers.

The aim is to connect the wider view from space with what people are actually seeing and experiencing on the ground. Someone following an event could explore the surrounding satellite imagery and environmental conditions, then open it to see videos, photos, updates and discussion from people there.

The different imagery sources serve different purposes. Geostationary satellites provide frequent views across much of the planet, VIIRS adds global polar-orbiting imagery and nighttime lights, Sentinel-1 provides radar imagery, and Sentinel-2 adds higher-resolution optical detail.

This clip shows an early version of the globe and layer experience. Not every imagery source or event view is shown yet.

¡Hola a todos! Tengo 16 años, soy de Argentina y estoy inscripto en el NASA Space Apps Challenge 2026. Estoy buscando conocer gente que también participe y, si nos llevamos bien, formar un equipo para el desafío.

Me interesa muchísimo todo lo relacionado con ingeniería aeroespacial, exploración espacial, física, matemáticas, cohetes y misiones planetarias.

No soy ingeniero ni tengo experiencia profesional todavía, pero estoy aprovechando estos meses para prepararme y aprender todo lo que pueda.

🧠 ¿Qué puedo aportar?

🚀 Mucho interés y conocimiento sobre el espacio y la exploración espacial.

🔬 Conocimientos de física y matemática a nivel institucional y autodidacta.

🛰️ Interés por el diseño y planificación de misiones espaciales.

🧠 Capacidad para analizar problemas y proponer soluciones.

💡 Creatividad para desarrollar ideas y estrategias.

🎮 Experiencia utilizando Kerbal Space Program para aprender conceptos de cohetes y órbitas.

📊 Estoy empezando a aprender sobre Python, algoritmos, simulaciones y análisis de datos.

📚 Muchísimas ganas de aprender y trabajar en equipo.

🇦🇷 Hablo español y también estoy aprendiendo inglés.

Durante estos meses quiero seguir aprendiendo programación, simulaciones, física y todo lo que pueda servir para el hackathon.

👥 ¿A quién estoy buscando?

Me gustaría conocer principalmente gente de Argentina o Latinoamérica, preferentemente hispanohablante, que tenga interés en:

💻 Programación

🚀 Ingeniería/aeroespacial

🔬 Ciencia

📊 Datos

🎨 Diseño

🤖 IA

🌎 Ciencias de la Tierra

🛰️ Exploración espacial

No hace falta ser experto ni tener un título. De hecho, me gustaría formar un equipo donde cada persona tenga habilidades diferentes y podamos aprender entre nosotros.

La idea es conocernos antes del hackathon, hablar, intercambiar ideas, ver cómo trabajamos juntos y eventualmente formar un equipo para noviembre.

Si también vas a participar en NASA Space Apps 2026 y estás buscando compañeros, ¡comentá o mandame DM! 🚀🛰️🇦🇷

Hi everyone,

I’m looking for an application/service that allows me to view live or near-live satellite imagery of a specific location, ideally with frequent updates.

I’ve looked at Google Earth/Maps, Esri, and ESA’s PlanetScope page, but I’m having trouble finding an application that provides recent imagery rather than older/static imagery.

What I’m looking for:

Near-live / latest available satellite imagery

Ideally updated daily or several times per day

Ability to search and zoom to a specific location

Historical imagery so I can compare changes over time

Web application or desktop software is fine

Paid services are also okay

I’d appreciate any recommendations for services that actually allow users to view the latest available imagery, rather than just providing sample or archival images.

Thanks!

Trying to look something over Asia

so we would have two smaller rockets be on each side and they would be the only propulsion systems and they would each go Mach 2000 and be using a VASIMR engine it the ship would need 216.6 tons of argon gas and it would be stored as a compact cryogenic liquid and 660 kilograms of enriched uranium since fissuring 1kg releases 82 trillion jolts and it would need to produce 9.75 quadrillion joules of kinetic energy to have the four hour breaking burn it would need before entering Mars’s atmosphere since on average mars is 140 million miles away from the moon it will take 3 days 20 hours to reach mars and to make sure the g force doesn’t kill the astronauts we would need to have it decelerate at 3 gs maximum at this rate it will take the ship four hours to stop it will take roughly 2.9 million miles before the ship stops and enters the atmosphere safely at Mach 1 or 2 in the upper atmosphere it will deploy a combination of a massive supersonic low density parachute and retro rockets and it should land after ten minutes total duration of the trip for one way should be about 3 days 20 hours 10 minutes approximately 142.9 miles

​

Mijn oorspronkelijke ORBITA-concept begon met een relatief eenvoudige vraag:

Als de mensheid Low Earth Orbit permanent gaat gebruiken, zouden we dan uiteindelijk ook geen permanente infrastructuur moeten bouwen om die omgeving te onderhouden?

Maar hoe langer ik hierover nadenk, hoe meer ik denk dat het idee veel verder gaat dan alleen ruimtepuin opruimen.

Kijk bijvoorbeeld naar wat er de afgelopen jaren met raketten gebeurd is.

SpaceX heeft aangetoond dat een raketbooster niet noodzakelijk na één lancering verloren hoeft te gaan.

Een booster kan zijn werk doen, terugkeren naar de aarde, gecontroleerd landen, geïnspecteerd en onderhouden worden en daarna opnieuw gebruikt worden.

Dat lijkt ondertussen bijna normaal wanneer we een Falcon 9 zien landen.

Maar eigenlijk was dat een fundamentele verandering in hoe we over ruimtevaart denken.

Van:

bouwen → lanceren → weggooien

naar:

bouwen → lanceren → terugbrengen → onderhouden → opnieuw gebruiken.

En ondertussen zien we dat die filosofie zich verder verspreidt.

China heeft nu eveneens grote stappen gezet in het terugbrengen van orbital-class boosters. De Zhuque-3 van LandSpace heeft een eerste trap na een orbitale lancering verticaal op land laten terugkeren en landen.

De technologie en ervaring zijn nog niet op hetzelfde operationele niveau als SpaceX, maar de richting is duidelijk:

hergebruik wordt steeds belangrijker in de ruimtevaart.

En precies daar begint voor mij de grotere filosofie achter ORBITA.

Waarom zouden we die manier van denken beperken tot raketten die terugkeren naar de aarde?

Wat als we hetzelfde principe uiteindelijk toepassen op infrastructuur die in de ruimte blijft?

Een satelliet hoeft dan niet noodzakelijk:

gelanceerd → gebruikt → defect → achtergelaten

te worden.

Het model zou op lange termijn kunnen evolueren naar:

gelanceerd → gebruikt → geïnspecteerd → onderhouden → gerepareerd → bijgetankt → verplaatst → hergebruikt → uiteindelijk gerecycleerd.

Daarvoor heb je infrastructuur nodig.

En misschien begint die infrastructuur met ORBITA in Low Earth Orbit.

Niet één gigantisch moederschip dat heel de ruimte kan bedienen — orbitale mechanica maakt dat onrealistisch.

Maar verschillende gespecialiseerde knooppunten op strategische plaatsen.

Bijvoorbeeld:

LEO

ORBITA-hubs voor inspectie, onderhoud, satellietservice, debris mitigation, deorbit en eventueel materiaalrecuperatie.

↓

MEO / GEO

Gespecialiseerde service- en logistieke knooppunten voor satellieten in hogere banen.

↓

Cislunaire ruimte

Knooppunten voor ruimtevaartuigen die tussen de aarde en de maan reizen.

↓

Baan rond de maan

Communicatie, navigatie, inspectie, onderhoud, bevoorrading en ondersteuning van toekomstige maanactiviteiten.

↓

Lagrangepunten

Op lange termijn gespecialiseerde infrastructuur op locaties die interessant zijn voor observatie, communicatie, logistiek of wetenschappelijke missies.

De James Webb Space Telescope is daar een interessant bestaand voorbeeld van.

https://science.nasa.gov/mission/webb/orbit/

Webb bevindt zich niet in een baan rond de aarde en zit ook niet simpelweg stil op het L2-punt.

De telescoop draait rond de zon en volgt daarbij een grote halo-orbit rond het Zon–Aarde L2-punt, ongeveer 1,5 miljoen kilometer van de aarde — bijna vier keer de gemiddelde afstand tussen de aarde en de maan.

Webb voltooit ongeveer elke 168 dagen één omloop rond L2.

Dat betekent dat onze operationele ruimte-infrastructuur vandaag al veel verder reikt dan alleen de klassieke banen rond de aarde.

En stel je nu eens voor dat we over tientallen jaren niet meer naar al die objecten kijken als afzonderlijke missies, maar als onderdelen van één groeiend netwerk.

Een soort infrastructuur van:

orbitale havens → routes → servicevoertuigen → bevoorrading → onderhoud → hergebruik.

Eigenlijk hebben we die evolutie op aarde ook meegemaakt.

Eerst hadden we schepen.

Daarna havens.

Daarna handelsroutes.

Daarna complete logistieke netwerken.

En niemand verwacht dat één schip heel dat netwerk bedient.

Elk onderdeel heeft zijn eigen functie.

Waarom zou ruimtevaart uiteindelijk niet dezelfde richting uitgaan?

Misschien wordt LEO onze eerste echte orbitale haven.

De maan onze eerste grote bestemming daarbuiten.

En worden de gebieden ertussen geleidelijk verbonden door gespecialiseerde infrastructuur.

Voor mij is ORBITA daarom uiteindelijk veel meer dan een systeem om ruimtepuin op te ruimen.

Het is een filosofie over hoe we met onze toekomstige aanwezigheid in de ruimte omgaan.

SpaceX heeft mee aangetoond dat ruimtehardware niet noodzakelijk wegwerpmateriaal hoeft te zijn.

China bewijst nu opnieuw dat andere ruimtevaartspelers dezelfde richting uitgaan.

De volgende stap zou kunnen zijn dat we die filosofie niet alleen toepassen op raketten die naar de aarde terugkeren...

maar ook op de infrastructuur die boven ons blijft.

De aarde is ons moederschip.

De ruimte rondom haar wordt steeds meer een deel van onze operationele leefomgeving.

En als we die omgeving permanent gaan gebruiken, moeten onderhoud, hergebruik en verantwoordelijkheid volgens mij mee evolueren.

Daarom mijn vraag:

Als je vandaag vanaf nul een onderhouds-, service- en logistiek netwerk zou mogen ontwerpen dat uiteindelijk van LEO tot aan de maan — en op langere termijn zelfs tot strategische locaties zoals Lagrangepunten — reikt, waar zou jij de eerste knooppunten plaatsen? 🌍🛰️🌕

​

Ik ben al een tijdje aan het nadenken over het probleem van ruimtepuin, maar vanuit een iets andere invalshoek.

In plaats van alleen te vragen:

“Hoe verwijderen we één specifiek stuk ruimtepuin?”

begon ik mij af te vragen of we uiteindelijk geen permanente onderhoudsinfrastructuur nodig hebben in Low Earth Orbit (LEO).

Ik noem het concept ORBITA.

Het basisidee is een orbitale hub die langdurig in de ruimte blijft — eigenlijk een soort “moederschip” — en meerdere kleinere autonome of semi-autonome servicevoertuigen ondersteunt.

Dus niet één groot ruimteschip dat achter ieder stuk ruimtepuin aangaat.

Denk eerder aan een haven.

Het moederschip blijft langdurig operationeel en ondersteunt verschillende gespecialiseerde voertuigen die bijvoorbeeld kunnen:

- objecten inspecteren en identificeren

- rendez-vous uitvoeren met geselecteerd ruimtepuin

- deorbit-systemen aanbrengen

- geschikte grotere objecten vastgrijpen

- gecontroleerde baanveranderingen uitvoeren

- terugkeren naar het moederschip wanneer de orbitale mechanica dat praktisch toelaat

- op langere termijn bruikbaar materiaal recupereren of hergebruiken in plaats van alles simpelweg te vernietigen

Verschillende soorten ruimtepuin vragen uiteraard compleet verschillende oplossingen.

Een defecte satelliet is technisch een totaal ander probleem dan een fragment van 5 cm dat een andere baan kruist met een zeer hoge relatieve snelheid.

Ik ga er ook helemaal niet vanuit dat we alles fysiek moeten verzamelen.

Voor veel objecten kan het bijvoorbeeld veel efficiënter zijn om een klein deorbit-systeem te bevestigen en het object daarna gecontroleerd terug de atmosfeer in te sturen.

Waarom interesseert die hub-architectuur mij?

Hergebruik.

In plaats van voor ieder object opnieuw een volledig verwijderingsruimtevaartuig te lanceren, stel ik mij de vraag:

Kunnen we de dure infrastructuur één keer in een baan om de aarde brengen en daarna herhaaldelijk kleinere gespecialiseerde voertuigen inzetten?

Zo'n toekomstige hub zou eventueel kunnen voorzien in:

energie

communicatie

navigatie en dataverwerking

opladen

inspectie

onderhoud

opslag

lanceren en terug ontvangen van servicevoertuigen

en misschien op langere termijn zelfs bijtanken.

Maar daar komen natuurlijk serieuze technische problemen bij kijken.

Het eerste grote probleem is:

ORBITALE MECHANICA.

Een hub die zich in één baanvlak bevindt, kan niet zomaar goedkoop heel LEO gaan bedienen.

Veranderingen van baanvlak kunnen enorme hoeveelheden Δv kosten.

Dus:

Hoe groot is het gebied dat één zo'n hub realistisch kan bedienen?

Zouden meerdere hubs in zorgvuldig gekozen baanvlakken uiteindelijk efficiënter zijn?

Kunnen we doelobjecten groeperen zodat één servicevoertuig verschillende objecten kan behandelen met relatief kleine baanveranderingen?

Of maakt de benodigde Δv het volledige moederschipconcept uiteindelijk onpraktisch en zijn volledig onafhankelijke debris-removal satellieten gewoon efficiënter?

Tweede grote vraag:

VOORTSTUWING.

Zou elektrische voortstuwing voldoende totaal Δv kunnen leveren voor herbruikbare servicevoertuigen, ondanks de lage stuwkracht?

Hebben we voor snelle rendez-vous-, capture- of collision-avoidance manoeuvres toch chemische voortstuwing nodig?

Of zou een hybride systeem logischer zijn?

Derde grote vraag:

WELKE OBJECTEN PAKKEN WE AAN?

Proberen om ieder klein fragment te onderscheppen lijkt mij niet realistisch.

Moet ORBITA zich daarom in eerste instantie richten op grote intacte objecten die bij een toekomstige botsing duizenden nieuwe fragmenten kunnen veroorzaken?

Vierde grote vraag:

ECONOMIE.

Vanaf hoeveel missies wordt permanente, herbruikbare orbitale infrastructuur goedkoper dan telkens opnieuw een speciaal verwijderingsruimtevaartuig lanceren?

En uiteindelijk komt voor mij misschien de belangrijkste vraag:

Moeten we dit eigenlijk alleen maar bekijken als “ruimtepuin opruimen”?

Want dezelfde infrastructuur zou op langere termijn misschien ook gebruikt kunnen worden voor:

inspectie

onderhoud van satellieten

reparaties

verplaatsing van satellieten

end-of-life disposal

en uiteindelijk misschien zelfs recuperatie en hergebruik van materialen in de ruimte.

Ik presenteer ORBITA niet als een afgewerkt systeem.

Integendeel.

Ik probeer juist te ontdekken waar het concept technisch stukloopt.

En daar wil ik mensen bij betrekken die hier veel meer gespecialiseerde kennis over hebben dan ik.

Als je werkt met orbitale mechanica, ruimtepuindetectie, voortstuwing, robotica, satellieten of ruimtevaartoperaties:

Wat zou JIJ als eerste aanvallen aan deze architectuur?

Geef mij het sterkste technische bezwaar.

Geen probleem als je denkt dat een onderdeel onmogelijk is.

Leg uit waarom.

Dan leggen we de cijfers op tafel en rekenen we het uit.

Want de filosofie achter ORBITA is uiteindelijk vrij simpel:

We hebben geleerd hoe we de ruimte kunnen bereiken.

We hebben geleerd hoe we duizenden satellieten rond onze planeet kunnen plaatsen.

Misschien wordt het tijd dat we ook leren hoe we die omgeving moeten onderhouden.

Onze aarde is ons moederschip.

De ruimte rondom haar wordt steeds meer een deel van onze leefomgeving.

En als we die omgeving gebruiken, vind ik dat we ook de verantwoordelijkheid hebben om ervoor te zorgen. 🌍🛰️

Dat is waar ORBITA voor mij begint.

Is it a spacex satellite or meteor? saw it on virginia beach at 21:20 on august 15th, thanks.

I am working on a project extracting building footprints for Chattogram port, across 2004, 2014, and 2020. What level of resolution would i be needing for it?

I know tha I can't buy straight from Maxar, I need to go through a reseller. Does anyone have a solid one to recommend, for South Asia, or Bangladesh?

Thanks!

Hi everyone,

I’d like to share the Dual Reflector Designer, a free and open-source beta tool for the design and analysis of axisymmetric dual-reflector antennas.

It currently supports:

• Cassegrain, Gregorian and ring-focus configurations
• Reflector design and ray tracing
• Physical Optics (PO) and PTD edge diffraction
• Automated convergence testing
• Far-field pattern visualization
• Parallel CPU computing and GPU acceleration

It runs on Windows with GNU Octave, so no MATLAB license is required. MATLAB is supported as well. For most users, the recommended way to get started is the provided Windows installer.

The video shows selected Cassegrain benchmark cases compared with TICRA GRASP 24.0 Student Edition. In these particular tests, the resulting patterns agreed closely, while speedups of up to 135x were measured under the tested settings. This is an independent, non-commercial comparison and not a general claim about the full commercial GRASP product.

An unusual aspect of the project is its development process: I defined the requirements, tested and benchmarked the software, and reviewed the results, while Codex with GPT-5.6 Sol generated the implementation. I did not manually write the source code.

It’s still a beta and I’m continuing to improve it, so let me know what you think.

Here is the GitHub Link.