It looks like the XML has PHR_ORTHO listed as the sensor.
Can you provide more information about the images you ordered (and product type or processing level)? Are your images Level-1B “primary” products, or the “projected” products? ASP expects the former. The latter are projected onto a constant height above the ellipsoid, and each of input images in the pair/triplet uses a slightly different height (presumably the mean elevation of each image footprint), at least based on the PHR samples I’ve explored.
In this case, the PHR_ORTHO value makes me think that you have orthoimages, with terrain displacement removed using some external DEM, which means these images cannot be used for stereo. Changing the sensor name in the XML will not solve the problem.
It’s important to order the correct product level (Level-1B in original sensor coordinates, after radiometric and geometric corrections) when the objective is stereo DEM production. This issue continues to come up, and I’m curious about the guidance provided by sales rep at Airbus or other contacts who provided these products. Some commercial stereo processing software (e.g., SOCET SET, ERDAS) supports the “projected" products, and in principle ASP can as well, but the quailty/accuracy of the resulting stereo DEM will be reduced, since we don’t have details on the interpolation used to go from “primary” to “projected” products. I hope that they are willing to redeliver products you can use for stereo.
If you can share the XML, we can confirm the issue.
-David
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
Hello There,