The satellite imagery industry still has no idea what customers want
joemorrison.substack.com
joemorrison.substack.com
This is basically right. The problem with space imagery is that almost everyone who wants it has a niche use case, and those few organizations without a niche use case (the US Weather Service, various militaries, etc) generally want imagery that's so specialized to their own problem that they have to spec, buy, and operate their own orbital assets.
Take Ukraine as an example. Leaving aside the moral question of whether a satellite imagery company should be profiting off the Ukrainian war, Ukraine appears to be using commercial orbital imagery providers to figure out Russian troop movements. That use case is not one any commercial provider anywhere is going to build an ML model for. But analysts working on behalf of Ukraine can absolutely either use raw pixels or develop their own ML algorithms that run on top of the raw pixels to find Russian tanks.
And almost every other potential user is similar. They're all looking for something different. Oil companies want to pre-screen drilling locations. NGOs want to look at deforestation in Brazil or methane leaks in Saudi Arabia. You could even go all the way down to individuals -- at the right price, individual farms might want to look at relative growth rates of corn in their fields, or soil moisture levels, etc. Or they might want to count heads of cattle or sheep, or... or... or.
The point being, outside of weather, which we already know how to get to end users without having them subscribe to an orbital imagery provider service, every customer is different, and what they want from the pixels is different. It's basically the long-tail problem. In order to be profitable you have to fill an enormous number of niche use cases.
Another analogy I use a lot: satellite imagery is like salt. The dish can have lots of ingredients (in a military context: HUMINT, OSINT, SIGINT, etc.) And the satellite imagery can make the whole dish. But you never want to consume it in isolation, that would be disgusting.
Certainly that’s true with eg the petroleum industry, and big ag.
Forget the algorithm. They need to fix their customer service, their sales process. Customers want pixels, but they need basic services: simple and a predictable price. I want to give a location (pix+radius, four corners or whatever) and a delivery schedule (once a week etc). But when I try to buy that stuff I get package deals, "ask for a quote", and vague statements about times. That doesn't work. Normal customers, ie not intelligence agencies, don't want a drawn-out negotiation process. The first company that can provide a basic web interface for purchasing imagery quickly and piecemeal will win the market.
Top of the list for small customers are probably high-end real estate agents. They want to monitor their neighborhoods for houses that are under delayed construction or backyards/pools that are being neglected (sure signs of someone ready to sell).
Civil litigation attorneys: I want everything you have about this particular intersection. Cops: I want any images you have of this house between these dates. News agencies: There is a Russian ship on fire at X location. When can you get us an image? And a great many other small customers I cannot think of at the moment.
I know satellites are getting cheaper but there are still limits to the cost of targeted image acquisition right? Is the price at which these customers are able and willing to pay enough to cover those costs?
For example it'd be a cool feature to check where my food delivery man is at in real time through satellite imaging but that can't possibly be a profitable use case.
Pixels are there anyway, and infinitely scalable - you can sell exact same pixels to infinite number of people.
So why not to make a very easy UX to extract the pixels of your choice as per customized timeline.
It almost sounds foolish not to do it.
This is the requirement. The timeline could be once a week, once a month or once a .. - the point is not frequency but predictability. With Google Earth, Open Source, et al there is no predictability, that's why they are not answer for THIS potential customer.
Market segmentation by ability to pay can mean cheaper imagery for a chunk of the market than a flat fee.
So for example non-SLA "once a week" might really mean "once a week except if any of these 4 million other things take precedence" and translate to intervals being skipped on a regular basis, photos being days or weeks old, etc. SLA'd once-a-week would really be once a week and not a second late, but truly prohibitively expensive.
I'm reminded of the early US telephone systems in the 60s and 70s around WWII etc where Important People could pick up a phone and always get a connection even if that booted off a few tens or hundreds of calls on a shared trunk in the call path. Satellite is like an order-of magnitude-worse version of that problem because of the associated eye-watering costs and subsequent plain old near-zero availability.
Or are we thinking of a satellite that can actually be targeted at things on demand - selling time or fuel?
This is basically corporate surveillance and I’m not at all comfortable with it. If you changed ‘real estate agent’ to ‘large landlord company’, the public would find this exceptionally unpalatable.
That's not generally true in the United States. If you are on public property, you can take a photo of anything or anyone you can see. You do not need their permission.
There may be local laws that restrict this, but they are not the common case.
https://en.wikipedia.org/wiki/Photography_and_the_law#United...
More detail:
Do you think you have a reasonable expectation of privacy anywhere ?
Sorry, can't seem to find it on the net after a quick DDG
These guys seem to be doing what you're interested in from the ordering side at least (Perth, Australia startup now gone to North America too).
But they use plane based images, so anything in a warzone is out
Plus, it doesn’t appear to be needed. The Russian military is proving to be god-awful at even basic field ops like camouflaging their vehicles.
https://news.yahoo.com/trump-tweeted-classified-satellite-im...
But the actual satellites can be seen with the naked eye, and their orbits are known. The resolution is a linear function of their height, so it can be easily inferred, or at least bounded, by that of a "hubble" at a much lower height. If they are really worried about this scalar piece of data, they can easily blur the images before transferring them to ukraine. Not that it makes a lot of difference to see a column of tanks at 30cm or at 15cm pixels.
Incorrect. Even in the consumer camera space, resolution is a function of distance, native sensor resolution, lens magnification, lens quality, shutter speed (because the target is moving), stability of the tripod, etc. Same thing is true of orbital imagery: your effective resolution is a function of your optics, your sensor, the ability of your attitude control system to hold a steady pointing vector, etc.
Also, "capability" != "resolution". What frequency bands is that satellite imaging in? Visible, SWIR, LWIR, ultraviolet? What is the effective magnification of its optics? Is it an optical system at all, or is it an RF bird? Is it all of the above? Does it just take top down snapshots, or can it track moving targets? If the latter how fast can it track? Fast enough to keep up with a tank, or fast enough to keep up with a fighter plane? How many frames per pass can it take? How fast can it slew to get multiple objects in the same pass? Etc.
Is there some way to email you? There isn't any contact information on your profile.
Trump already did this when that Iranian something-or-another blew up (missile silo? nuclear reactor?) a few years ago, and he provided classified satellite images to the pubic
Beyond that, sure
But this is a good problem. It's like saying "the problem with motors is that everyone who uses them has a niche use case" (submarines, cars, airplanes, industrial machinery...). Or that "the problem with microscopy is that everyone who wants it has a niche use case". And indeed it does! Microscopes for biologists are different to those for chemists, engineers, medical doctors, physicists, etc.
The concept of "space imagery" is extremely wide. It is natural that earth observation satellites become specialized. I wouldn't be surprised to see in the near future some "CH4" or "CO2" satellites that acquire light in a handful of extremely narrow particular bands on the short wave infrared spectrum that are useful only for observing plumes of these gases. Right now, people use hyperspectral imagers (which have a dense sampling of some parts of the spectrum) and throw away most of the image data.
What you don't do is presume that you know everything about how people want to use motors, and offer a subscription to a design service that does all of their engineering design for them, as a way to sell your motors.
The false assumption I deal with that drives me insane with so many individuals is that everyone thinks their specialized use case is a small variation on the major use case that already benefits from economies of scale. That often isn't the case and a significant R&D effort needs to go underway on just how one can leverage existing technology for their use case.
There's very often at least one, if not many, mission critical functional requirements from existing tech that require significant effort to make the jump from the existing tech to the desired use case. And guess what, all the non-niche users don't want to pay for that, so you need to be prepared to pony up the capital, accept risk of failure, and be ready to take the plunge.
I tell people with this mentality that they need to work in reverse, first understand the technology they think is close and find the problem sets that have the best match up and focus on those. These efforts can costs hundreds of thousands very easily if not millions to tens of millions if you just play it by ear that "...this thing is sorta like what we want so it can't possibly be that difficult to adapt." (Basically what I hear with technology management, many business people, and clients)
Many people pretend software and tech are just Lego blocks and since it's virtual, there's no capital needed. Good luck, because the skills needed to deal with this tech isn't cheap and the complexity often isn't low meaning expensive and difficult to find labor for long periods of time, often with a fairly good chance of failure.
Or, abandon all of that. A space imagery company is a media company. They generate content. So do what other content creators do. Take everything you have and shovel it in front of people as fast as possible. Deliver it by any and every means available. Ask questions, but do so AFTER they have already made a purchase. Then judge what your customers want by what they choose to consume.
Say I'm a farmer and for examples sake I want regular aerial images to estimate crop yield for a plot of land. That would require high resolution imaging of a particular patch everyday for maybe a few months. That would require purposeful data capturing at regular time intervals during overhead satellite passes.
From what i understand satellite imaging companies won't happen to just have those images containing the region of interest you want just lying around on their hard-drives which they can pull out with some query. If they make all the images they have available to the public, I'm guessing most of it will be useless to people considering it needs to cover the desired region of interest across time and space.
This is a good analogy. How many companies say “I’ll build a sweet motor and then find a customer for it”? They don’t. They build the motor for the application. (More often, they build something close to the final product.)
When you look at smaller motors (e.g. DC motors in handheld consumer products), they're basically jellybean parts targeted towards the highly specific use case of making a shaft turn.
Wrong. They absolutely do. In fact I’d wager the vast majority of motors are essentially commodity goods. Even if you were thinking of just combustion engines, its really not the case, most engines get reused many times. Which makes sense, its an outsized engineering problem to optimize so you’d want to maximize your return.
For example. https://www.mcmaster.com/electric-motors/
Interested to hear Mr. glen's opinion about that approach.
History has shown that when you sell something for less then you pay for it; hoping that users don’t fully use their credits to cover that loss; that time is not on your side.
They are already the walking dead.
>individual farms might want to look at relative growth rates of corn in their fields, or soil moisture levels, etc.
a LOT of people want this, but they would never pay $x,xxx/month for that, ever.
Eos (iirc it’s been a while) actually let me buy some imagery, but they would only give me pictures, not actual georeferenced rasters.
The actual manipulation and use of the data, even for machine learning, is pretty straightforward these days with ArcGIS. So yes, I want pixels.
And I can imagine the cheaper customers are a lot less educated and don't have the right expectations, like how often their target area is covered in clouds.
I work for John Deere. I can't speak for the company. I'll confirm we are intersted in imagining, but I won't comment on our plans to deal with the above issues.
Why not? It's been a while since the west has had a war where the moral details are so clear. If I had a company like this I'd be jumping on the opportunity.
Is this really true? I guess I can believe it, but it seems strange that the United States is sending over $800 million in weaponry, but won't send over satellite imagery.
I'd guess this is because you can't publish satellite imagery without revealing a lot about your intelligence gathering capabilities.
I've realised that that might still be a viable option once I started to map the forrest cover in my geographic area based on 150-years-old maps (these excellent maps [1] drawn by the Austrians in the 1860s). Some JS-code for the front-end that helped me "draw out" the forests, then send that data to a Django/Python backend and call it a day. It took me a while to draw those forests out but the job was very easily scalable in terms of human-power, i.e. 10 more me would have probably finished it 10 times faster with a little coordination (for anyone curious the data is in here [2], I'd say it was almost 90% done when I passed on to my next project, as I often do). I was first looking at using some heuristics in order to "automate" some part of the job, but both the false-positives and the false-negatives were just too high, the outputs would have been horrible in terms of accuracy.
[1] https://maps.arcanum.com/en/map/secondsurvey-wallachia/?laye...
[2] https://github.com/mihaitc/forrests/tree/master/counties
OpenStreetMap needs good imagery for mapping trails and buildings.
Off-roaders and overlanders need good imagery to verify the existence and state of trails.
That's just me, so I'm sure that there are tons of similar low key use cases.
I see that he outlined a few exceptions at the footnote… I'll also add Plaid. I think this guy is making some huge generalizations that don't hold up beyond his industry.
But that said, I recently downgraded two potential startups based on data feeds to personal projects because I realized that nobody really pays for data, and if there is any value then the providers will figure that out inevitably…
Another recent example: I've been using Deliveries for Mac and iOS for over fifteen years, a very simple, perfectly-designed, laser focused app. Both Amazon (not surprising) and Fed Ex (quite surprising) have decided that freely providing delivery dates to consumers is too valuable to leave to third parties, so the beloved app is shuttering sometime this year. https://junecloud.com/journal/iphone/the-future-of-deliverie...
...or to leave to the shipping endpoint customer, either. I can't tell you how many clicks it takes to determine when a particular shipment will arrive at my door. Off the top of my head:
0. Email from vendor: "your package has shipped!"
1. Log in to the Fedex account.
2. One would think that post-login that it would take your straight away to the "Manage Your Deliveries" page, because what is the most common action taken by a residential customer post-login? (My guess is, they want to find out when their stuff is going t show up.) But alas, no. It just takes you to the main page, but now you're logged in.
3. Search for that deliveries page...what is it called? Oh, wait, here's a Track button. Nope, that's not the one you want. Go click some more.
4. Finally find the Manage Your Deliveries option in some buried menu. Click it. It won't take your directly to the shipment that you originally were looking for, but it's in the neighborhood.
5. Ah, the Manage Your Deliveries page, where I can find out when the package will arrive.
6. "A label has been created, but the shipment hasn't been dropped off yet, so we haven't the first fucking clue when your package will arrive. But be sure to come back tomorrow to do this whole exercise again!"
I'm almost to the point of preferring vendors that use DHL instead of FedEx. It's that bad.
But telling me I'm doing it wrong for using an advertised feature, yeah, that's less than useful.
Otherwise, you just get the "master tracking number" delivery estimate which seems to be based off of the first box delivery date, not the date all the boxes will have arrived.
There's probably a good reason things are that way for delivery tracking (see chesterson's fence). But the rabbit hole doesn't end there! Reports generated from their own customer portal don't include per-box delivery dates. They all show the delivery date of the FIRST box. This is extremely frustrating when trying to make accurate models for forecasting, or even just lead time estimation.
They do this to make it harder to compare their services to competitors like DHL (oodles better than FedEX - but there are risk management considerations and also capacity issues) and it ends up harming businesses trying to serve their own customers better. This is especially annoying since they have really granular data internally that go into even more detail than just delivery date on a per box level.
Attached is a screenshot of a spreadsheet fed by some internal SQL database and macros that can spit out per box information including delay reason (weather, transit, act of God) and even number of hours late.
https://ibb.co/k3sNxYz macro / control sheet https://ibb.co/Zzjw8TV selected column titles
If anyone at FedEX is reading this please consider pushing the narrative that your business customers aren't the end of the line for the goods you move. If anyone who DOESN'T work at FedEX is reading this, I can email you a redacted copy of the spreadsheet I referenced above (just send it to tepitoperrito AT 420blaze DOT it).
I use the UPS version as I get alot of UPS packages. They typically email me once the shipment is picked up, typically before the sender does. They have a dashboard where you can see all inbound shipments as well. This requires registration and address validation, but not a UPS “account”.
I don't know your situation but it always seemed to be streamline for me to be:
0. Email with tracking number 123456789
1. https://www.fedex.com/fedextrack/?trknbr=123456789 into address bar
So here is what I do:
- open the mail link
- log in
- go back to the mail program and open the link again to bring me to the page I wanted to see in the first place
Would that work in your case?
!usps <tracking-number>
!fedex <tracking-number>
!ups <tracking-number>
Do you mean as an investment or place to work? And what type of data feeds were they, broadly?
I managed to put together an MVP of a service that would push notifications for stuff like "tell me when my favorite musicians/novelists/artists have new consumable," all the while thinking "if any of these people were smart they would have done this a decade ago." Of course Amazon started pushing out the book stuff, and Apple Music with music, just a few months after I got the back-end APIs working.
uh, so yes… grind, I guess
But that got old and started researching satellite options. Problems was our company entire sales area was three West Michigan counties. All the companies wanted to sell me, I forget the term but say a tract (scene?), that was half the state.
I didn't have a problem with the price per acre but wanted to buy by the section or 640 acres. It didn't make a lot of sense to buy the township but they wouldn't even sell me by the county. At the time probably 5% of my customers wanted this service and only wanted to buy just part of their acreage.
I asked all these vendors why they couldn't sell me by the township. They routinely answered they'd lose money because they couldn't sell the rest of the tract. I said now you understand my problem, at a certain point you've got to break up a tract or give up on the market. Most of the company's ended up leaving ag.
I eventually found a company that would sell by the section at a higher but still manageable price. Course then I discovered that in four flyovers a season the majority had clouds over the field and you couldn't see anything ;<(. Such is the pain of being an early user in any field.
FYI The military has satellites using radar to see through the clouds, but in thirty years that tech hasn't made it to the commercial operators.
The answer I think is automated drones that fly a circuit. The tech has been available for a few years but the government won't approve it for that use. In fact the FAA won't even let a Detroit company demonstrate they could successfully evade objects, they ran out of funding and shut their doors ;<(.
Planet at least will let you pay per pixel for their PlanetScope data (3m res) and with a daily revisit time you are guaranteed at least a few hits per month in the growing season.
The surface of the earth is huge and given the high-resolution close-to-realtime imagery that most people want, its not really possible to provide standardized sets of images that just happen to cover the region-of-interest for everyone right? Hence the need to targeted imaging.
On the flipside, if you put forward transparent pricing but it’s too high, it will stop prospective customers coming.
And they might be falling into the trap that the original article points out by trying to offer you processed data instead of being laser focused on having the best data sources and API.
Profound. And True. Sometimes I wonder whether we can truly call them learning models at all.
I also want to emphasize that I do not view bias as a bad thing in the context of supervised models. In some ways, I think it's the whole point of a supervised model (to inherit the judgment of its creators). If the bias helps filter predictions that are useful for your goals, it's a good thing.
1. People don't want satellite data they want their problem to be solved
So a company like Planet shouldn't (just) get satellite data they should solve problems.
2. Companies can't do 2 things at once well
So Planet actually has to choose between solving problems or just getting satellite data
3. Companies like Arturo have good focus and solve the problem of climate risk for insurance
So Arturo should stay focused on that, but where do they get the data from? Planet right? So Planet does have a set of customers for its data?
--
Edit: I re-read the article and maybe I'm just confused on the wording. Is he saying that raw data is valuable and worthwhile for satellite companies to sell but they should not do anything to the data before try to sell it?
* Just sell data or;
* Just sell applications powered by your proprietary source of data
Do not:
* Sell derived/refined data as a half-measure
* Sell both applications and wholesale data at the same time
If you feel like that doesn't make sense, you are not alone. Almost everyone in the industry disagrees with my views on this topic based on how they run their businesses. Satellogic is one notable exception. But I can't think of a single other provider that would agree with me.
Bloomberg comes to mind since they offer wholesale access to data in addition to all the terminal functions.
I've heard so many founders try to describe their business as "Bloomberg for.." when trying to describe a mixed focus offering of products that I immediately hear alarm bells nowadays.
(1) is a desktop (and now mobile) application that trader, sales, etc. use to communicate, view raw data, and view derived data in "mini-apps" (price this bond under scenario X, etc.) The base cost is about 25K USD per year (there are local IT costs above the terminal license fees). There is a raw data access API for Excel, but very limited. They block your API access if you try to download too much data. The days of pricing any kind of volume of products from a Excel Bloomberg API is mostly gone. Also, you cannot run it on a server and just screen scrape / use data API all day long.
(2) is a raw data feed service, akin to Reuters. Not well understood by industry outsiders: There is no "all you can eat data service" anywhere in finance. Period. Every primary data source is now carefully guarded with license costs and special rules (no redist, etc.). Some stock exchanges make more money selling data licenses than collection trading fees! I have no idea about BPIPE prices, but I assume expensive and per data source with nearly infinite granularity.
About revenue: (1) Wiki says: https://en.wikipedia.org/wiki/Bloomberg_Terminal
If you believe it: 20K USD per terminal and ~325,000 terminals as of 2016. That is 6.5 billion USD per year. Nice.
About revenue: (2) No idea. I cannot find any reliable published stats.
Lastly: I regularly see people argue on HN about an open source version of Bloomberg. It is impossible for two reasons: (a) Network effect in the communication channels -- lots of people mostly use Bloomberg chat / email and hardly use data, besides the trivial. Most people on the buy side (money management, hedge funds, portfolio managers) join Bloomberg to talk to other people on Bloomberg. And: (b) data licensing.
You don't always have to order the biggie fries and drink, you can just order the standard meal.
The OPs point is that it won’t be profitable/effective, that’s all.
And its not just Planet that is hung-up on this same failed business model. Its also Hexagon, and a myriad of other earth-observation providers. Some are so difficult to work with its literally cheaper to go buy an airplane and a wide format camera and roll your own.
There’s a new one like every picosecond.” It’s “delivery, but for dorm rooms” for space tech.
Disclaimer: never actually used their system, just saw presentations about it, which show how one can train an algorithm to count... stuff.
What we are trying to do is indeed allow customers to build algorithms tailored to their use cases. We often joke that the reason our ML works is because we are overfitting to customer datasets/use cases. But I think that's somewhat true in the sense that we are not going for "worldwide trees counting" but more for "reliably count cars on these 50 parcels".
It's also interesting to note that a sizeable chunk of our revenue is coming from companies with drone data where it makes even more sense to be specific to customer data (resolution, time of day, geo, etc...).
If they wanted to be crushing it, lower the cost/ barrier to entry on the pixels themselves. Get it out into peoples hands and use more open, easier to build on licenses. Let people actually use the data.
I've been on the other side of 5 failed attempts to work with Planet at large, medium, non-profit and startup scale projects, as early as 2016 and as late as 2021. They just don't get it. If your data isn't easy to use, I wont. If your license is going to prevent me from building what I need to from that data, I wont use it.
There is a large market gap between the sensor platform providers and the would-be end users of that sensor data. Business is constrained by the fact that the end users are not capable of consuming what is being produced and neither party in the transaction is really qualified to solve that problem.
Sensor platform companies can't make their data more consumable because they only know their data, not the analytic nuances of the end users nor the other sensor modalities that the end user may be using. They try, with the hope of improving revenue, but it almost never comes off. The end users are experts in their analysis problems and application domains but usually have no skill or capacity to write custom performance-engineered infrastructure software to bring the sensor data into their domain. This software often has pretty hardcore computer science requirements and there is minimal tooling, certainly not in open source, to make this easier or more scalable. There is clearly a market opportunity, but neither of the obvious parties is in a position to address it even for their own immediate benefit.
There are a few companies with expertise in building high-performance data tooling for analytic workflows across sensor modalities with enough application understanding to bring it into the end user's domain. There is a lot of commonality across application domains from the view of tooling requirements but you have to have expertise in several vertical domains to see it, so it is repeatable. These companies have neither the data nor the application but they bring them close enough together that they can "make the market" as it were. Currently this is a high-end contracting business rather than a general platform, so it doesn't scale. But if this tooling became part of a general platform, it would let the sensor data platforms focus on data collection without worrying about how to make the data more consumable for various application domains, which they were failing at anyway.
The state of software tooling for these sensing data applications is primitive, overfitted for single data sources, and not nearly scalable enough. Most other problems in the sensor data market are consequences of this reality.
The workloads and computer science are very different, but bringing them together would add a lot of value. At least with current platforms on the market, one is always to the exclusion of the other.
This is mostly true, though I will add there are some repeatable insights that people will pay for. In the financial sector, there were plenty of people who paid for car counts data back in 2016 (though many customers did not renew) and there are still people today who are interested in oil inventories data, and mall traffic data (though satellite data is being augmented there these days). The general theme of the piece is correct imo though. When the company I worked at started, we thought there would be many use cases, it became clear after a while there were only a few insights with large markets, and after that a really long tail of custom asks.
To your article's point, I believe my company ended up trying to switch to a platform that allowed people to create their own insights, but im not sure how successful that was in the end
I am not rooting for people to fail. We’re building an industry together, not playing a zero-sum game
This is a cool industry, because most of the effort is going toward things like monitoring the effects of climate change, or mapping natural disasters in real time to support crisis response, or illuminating human rights violations around the world. Rooting against the people working on that is icky.
In my opinion, we're all competing against obscurity (who buys satellite data today?!), not each other.
I really understand the author's argument that lots of satellite companies are "doing this wrong", by investing lots and lots of resources into "new products" that cost a lot of money to produce but don't have a clear user story, but I wonder if there's a way to do this "right" by building very simple, customizable software that lowers the floor in terms of what sorts of customers are able to purchase satellite data feeds? Maybe even using the same software the CountThings does?
This seems to be qualitatively very different from the types of "data feeds" that OP is talking about that try to measure "useful analytics", rather than working on a scalable process for shipping bespoke solutions to customers with turn-key integration. This is (one way) to tackle the long-tail problem. But maybe it runs into some other pitfalls
I've watched the area of commercialized remote sensing products with some interest, because I'm in the non-commercial remote sensing line.
The way NASA handles derived data products is (broadly) through "levels":
L0: measurement, still in instrument native units (e.g., DN's)
L1: calibrated and put into physical units (e.g., watts/cm2)
L2: scientifically-useful product (surface reflectance at 450nm, CO2 concentration)
L3: L2 that has been aggregated into a map, possibly also across time or instrument
L4: data has been filtered through a time-stepped physics-based model
One advantage of the above decomposition is that L2-L4 data can be validated with in-situ measurements. They are not just indexes -- they are targeted at a certain physically-measurable quantity.
This allows judgement whether the intermediate products (L2 CO2) are actually good, or improving. It also allows combining intermediate products from different sources (which is a hard problem). This is because both sources are trying to measure the same thing by design.
It is true that (for example) current spectroscopic remote sensing allows retrieval of a lot of L2 products for diverse communities -- scores of products, from mineral abundance to urban land use to agriculture to snow/ice to algae.
I do agree with OP that it will be impossible for any company to "cover the waterfront" of even half of these products. The measurement and each individual product take a lot of effort to get right.
But it also seems like there are commercial opportunities for some specific such products -- e.g., methane concentration/fluxes, or Evapotranspiration/soil moisture.
Wouldn't a subscription-based service to these products allow for continuous improvement of the underlying product, either through new measurements or through better algorithms?
So, in a nut, in the context of OP, what's the difference between:
-- an always-improving subscription-based "vertical service" for a L2 product like I just described,
vs.
-- a "problem-solving application" like the OP is advocating?
There are two hallmarks of an application that differentiate it from a data service:
1. Earth observation is a minority of the data that it manages and maintains
2. Users are not just presented with information, they are prompted to take action
I would argue that levels L3 and L4 are probably falling into the same trap as the data feeds I described in the blog post. Do you know if USGS publishes download metrics are available for each dataset associated with Landsat, for instance? I bet if you made a ratio of time/investment to downloads, you'd find L2 outperforms all other categories. But I could be wrong; I have never seen the download data and don't know the relative levels of effort to produce each dataset they offer.
I.e., the value is in a complete "application" solution to a given problem rather than in hoping for a "killer remote-sensing data product" that would (in theory) solve the problem?
About your question, I'm on the analysis side, not the infrastructure side, so I don't know about the download metrics - they must be tracked but a quick search didn't turn up anything accessible. The download metrics aren't super-valuable because lots of people/groups do programmatic downloads -- the cost is zero.
I think the L0-L4 distinctions is trying to illustrate these points:
-- L0, L1 data are sensor-dependent and not really useful to solving problems
-- There's a lot of value in developing calibrated data (L2+)
-- Basic visual imagery often isn't calibrated so subsequent processing will necessarily be ad hoc and thus of limited value for any consequential decision-making
The satellite industry is an incredibly high-walled garden. Launch costs are falling and the use of off-the-shelf hardware combined with smaller satellite forms is improving revisit, but it's a steep hill to climb no less. Custom-built monitoring algos are subject to diminishing returns based on a variety of factors and the number of images in a data set is certainly part of that.
* Satellite provider or analytics firm sells "car counts" for retail stores
* Financial institution is intrigued; this must correlate with sales, right?
* But..why don't we just buy credit card transaction data and foot traffic data from clearing houses and GPS trace providers?
I often liken satellite imagery to salt. It's great to finish a dish, but should never be consumed alone. If you don't believe the foot traffic data or credit card transaction data you're buying, you can use satellite data to check it or refine the model. But that's a niche within a niche.
The other issue I pointed out in that article is customer savvy--if you're a quant fund sophisticated enough to make use of an arcane data feed, you're very likely sophisticated enough to generate that feed yourself from raw data. And if you do it yourself, it's suddenly part of a "proprietary" solution. So you'd rather just buy images and do the heavy lifting that pay a premium to buy a data feed that doesn't quite solve your problem by itself.
Problem is that most the interesting bits people want more data on are quite dynamic in space and time, not just time. Even when it's not you don't gain linear subsampling improvements and eventually get diminishing returns with such approaches.
If they really want new customers they should make this more accessible to laypeople.
Are you aware of ways for a hypothetical start-up team to get cheap/affordable raw imagery data to attempt this? Instead of paying B2B prices upfront just for experimentation?
I want worldwide 24/7 live video footage. I want with enough resolution to identify letters on a printed page on the ground. And, I don’t want it to cost the entire global GDP to make and operate.
Get cracking.
So that one can order a pencil-sized AGM from some nation-state toward the vicinity of the carjacker or something.
To just outside the reticular.
Imagery providers doing insights is like a bunch of record company execs starting their own rock band.
I could write about this all day, but I'll start with the obvious: you're competing against a forecast that may have been made 30 minutes ago, an hour ago, 6 hours ago, 24 hours ago, or sometimes even more. So in some cases, at best you might be alerting people that something they already expected to happen is, now, actually happening. How useful that is depends on the context. Detecting a wildfire as it ignites? Cool - but most likely, if it's near an urban area, people already saw the smoke, or people were already ready to react because a Red Flag warning was posted. Lightning strikes? Folks already heard the thunder, and hopefully would've seen a risk of thunderstorms in the forecast earlier in the day or prior.
Carefully and succinctly incorporating narrow weather observations into existing forecast and alerting systems as a way to buttress them, decrease noise/boost signal, or otherwise capture a tiny bit more value than what was already there might work. But beyond that I struggle to see massive amounts of value for most of the use cases that many industries or communities wrestle with regarding weather alerting.
The new title of this post is much better, thx - it's kind of tldr.