Sorry, not correctly, of course, I put it - I am interested in EXPORT from SNAP in the format of KMZ!
Great to see what a bit of teamwork can achieve.
Thanks @ABraun and @marpet for your engagementā¦
@River-plate - thanks for your question and discussion also. The Third Party Mission handling team at ESA will be happy to know that people are using the data in a useful manner.
1 Like
I join and express to all forum users for their help! I opened the images in SNAP, what is needed - the water level in the river in the ALOS image is 3.5 meters less than in summer, so it will now be easy enough to make isobaths and color polygons of depths in shallow water. But export to the KMZ format really does not work - how to solve this problem now? I also tried to export to a regular picture - but also to no avail. You can, of course, just make screenshots from the computer screen (and I have two screens - itās convenient, they cover a large area) and then link it to Google Earth, but Iāll wait - can the problem be solved? If you are interested, then here is the section of my website on the bathymetry of the Kama near the city, I will add information after finishing work on the depth map - now it became clear that only joint work with the logs of the echo sounder-chartplotter and satellite images on the low water level in the river makes it possible to build a depth map accurate enough http://river-plate.ru/Š»Š¾ŃŠøŠø-Šø-ŠŗŠ°ŃŃŃ-Š³Š»ŃŠ±ŠøŠ½/.
Please give more details on this. What exactly is the problem? Do you get an error message?
When trying to export to KMZ format, SNAP writes to me: āproduct must be in āGeographic Lat/Lonā projectionā. Can then export to Geotiff, and then convert to KMZ?
Only data projected into WGS84 can be exported to KMZ. But as marpet wrote, this is currently not possible for this kind of data.
Export to Geotiff and then conversion to KMZ?
Iām not aware of a software which supports that
Hello! I just wanted to thank you for the clarification on this problem, and to let you know that I will be very excited once the issue is resolved with the ALOS Reader!
(I am primarily interested in analyses that must be performed outside of SNAP, including stereo photogrammetry, but would very much like to be able to use the ALOS Reader as a convenient way of map-projecting the PRISM images. That would greatly ease the necessary step of solving for internal/external camera parameters for photogrammetric work.)
Since Iām already writing here, I suppose I should double-check: Am I correct to assume that, without the reprojection function working properly, it is indeed impossible to export a PRISM image from S3T with its map projection intact?
I just had an idea how to overcome this issue.
It is possible to create latitude and longitude bands by using the Band Maths and the āLATā and 'LONā expressions. With these new bands a Pixel-GeoCoding can be attached (Tools menu).
After doing this the data can be properly reprojected.
Preferably on a subset of the image. Otherwise creating the Pixel-GeoCoding uses a lot of memory and might fail if you donāt have enough RAM.
@jfbrown
Maybe you donāt need to reproject the images. Maybe the created lat/lon bands help you in other tools?
Thank you for this suggestion. It more or less worked, but only for a very small area. If I used a subset much larger than 250 x 250 pixels, the Attach Pixel Geo-Coding step still worked fine, but the Reproject step would stall out. I will see if I can export the lat/lon bands to compute the desired image transformation in another tool. Iāll let you know if I figure it out!
Regarding the original ALOS Reader issue, I noticed something that might be of assistance in diagnosing the problem: the SCENE_LOWER_RIGHT_LONGITUDE from the ALOS Map Projection metadata is incorrect when the file is read into SNAP (S3T).
For example, the correct LR Longitude for the scene ALPSMN234012875-O1B1___N is 44.1245275 (from the LED-ā¦ file for that scene), but in SNAP the SCENE_LOWER_RIGHT_LONGITUDE is given as 35.8372995, which is just a repeat of the SCENE_LOWER_LEFT_LATITUDE. (See the screen capture attached below.)
I checked to see if this same substitution (where the LL Lat value appears in place of the LR Lon) occurred in other PRISM scenes as well, and it was exactly the same in every scene I loaded into SNAP. Could this be related to the incorrect spatial footprint when reprojecting the PRISM scene?
Thank you for all your help!
Well spotted! But the issue is only in the metadata. The wrong value was used. But those values are not used for the geo-coding. The values below, the coefficients, make up the geo-coding.
I checked if there is such an issue too, but havenāt seen such.
The metadata issue will be solved with the next release.
[SIIITBX-395] Metadata value SCENE_LOWER_RIGHT_LONGITUDE is not correct for ALOS - JIRA (atlassian.net)