Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orbital Analytics end-to-end solution using downlinked .bin data #80

Open
ivo-andreev opened this issue Sep 16, 2022 · 4 comments
Open

Comments

@ivo-andreev
Copy link

ivo-andreev commented Sep 16, 2022

The proposed sample uses a sample GeoTIFF .tif file, which is downloaded by
deploy/scripts/copy_geotiff.sh script and afterwards converted to tiles.
However there does not seem to be any documentation on how to produce such GeoTIFF from the Azure Orbital .bin file downloaded at the end of
https://docs.microsoft.com/en-us/azure/orbital/downlink-aqua.

The instructions https://docs.microsoft.com/en-us/azure/orbital/satellite-imagery-with-orbital-ground-station also do not address this topic, hence there is a huge gap between these two tutorials.

The only relevant instruction available is the utilization of demodulation to reduce .bin file size, but not about the product.

@mandarinamdar
Copy link
Member

This is not in scope for this sample solution and associated article. This sample solution takes geotiff from any data source

@ivo-andreev
Copy link
Author

Happy to have the confirmation above as exactly this is the reason to report the present issue - the solution is not end-end. If Orbital downlink data is not in scope, then how is that sample relevant to Azure Orbital and referenced by the Orbital documentation ?

Please refer to the link (your are a contributor in the article):
https://learn.microsoft.com/en-us/azure/architecture/industries/aerospace/geospatial-processing-analytics

This architecture is designed to show an end-to-end implementation that involves extracting, loading, transforming, and analyzing spaceborne data by using geospatial libraries and AI models with Azure Synapse Analytics.

From my point, and guess those coming after me, there is a huge gap, namely automating a pipeline that processes the .bin file and would become an enabler of an end-to-end solution, so that Orbital could be useful.

Please point out for the community to whom is that gap relevant. Thanks.

@jfrazee
Copy link

jfrazee commented Sep 20, 2022

Hi @ivo-andreev, thanks for the feedback. As @mandarinamdar comments, the stuff here is more about processing analysis ready data and can be used with or without the Azure Orbital Ground Station (AOGS).

From a manual processing perspective, you're looking at the right docs -- downlinking the data and then turning it into an analysis ready format:

  1. Downlink data from NASA's Aqua public satellite
  2. Collect and process Aqua satellite data using Azure Orbital Ground Station (AOGS)

You can get TIFF from (2) but that's not the only option.

I can point you to https://github.com/Azure/azure-orbital-integration which has assets for (1) and (2) and the part of the pipeline you're talking about.

It's hard to know where to draw the lines since as examples this stuff is already pretty heavy weight. Currently that line is drawn between stuff that ties directly into the ground station service and stuff that could come from any source or archive. We'll put some effort into clarifying this in the repos and the docs.

@ivo-andreev
Copy link
Author

@jfrazee Thanks for chiming in, feedback appreciated and quite relevant in this form. The 2 extra tools for processing the .bin file are referenced by the documentation, but the issue is that there are no instructions on how to generate a similar GeoTIFF.
The documentation states "We're interested in the MODIS Aerosol L2 (MOD04) product, which is produced by IMAPP SPA" and this is not Earth surface photo https://learn.microsoft.com/en-us/azure/orbital/satellite-imagery-with-orbital-ground-station. There is an additional complication by the fact that the downlink data from satellites is not the same and depends on satellite instruments available(probably a list of few satellites and the required instrument would fit nicely) . Finally - the whole process needs to be automated (i.e. using a shell script) so that there could be practical value out of the whole thing - i.e. bash script to export GeoTIFF. Hope you see the problem - otherwise there shall be a human taking the .bin file and using GUI tools which prevents the practical application of Orbital - we downlink to get data in order to derive valuable insights and if this depends on nontrivial human actions, we would better use a service to download images instead of Orbital.
I accept your point about the line, but whom shall we contact to get that gap addressed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants