Hi,
I have ALOS-2 PALSAR-2 L1.5 scenes in GeoTiff format that I’ve not yet been able to geocode. I’ve tried using SNAP v7.0 and Gitasar, but I can only get these to geocode the CEOS format data. Is there any method available within SNAP v8.0 for geocoding these scenes? I’m not able to download the data again in CEOS format due to the large costs involved. Alternatively, does anyone know of a python image processing library that would be capable of geocoding these data?
Thanks!
Level 1.5 Geotiff products are missing metadta information which are required by most programs for correct handling. Even ERDAS Imagine doesn’t support this format:
If there is no topography in your area, you might be lucky with the Mosaic operator as suggested here: ALOS-1 L1.5 Terrain Correction
out of curiosity: Why did you order Level-1.5 data at all?
Thanks for your response. I think I’ll just have to give up on using the Geotiff products altogether.
I inherited all of the L1.5 Geotiff and most of the L1.5 CEOS scenes I’m using from others who had initiated the project. It was realised later that ordering the Geotiff scenes had been a mistake as there seems to be no way to post-process them. The CEOS scenes at L1.5 are still useful for looking at flood extent mapping, but in retrospect the L1.1 scenes would have been a better option. My PhD supervisor receives a quota of 20 free scenes a year, but this isn’t enough to re-order all the geotiff data in CEOS format unfortunately, or at L1.1, and the scenes are very expensive otherwise.
Also, I’ve been able to use the mosaic trick with a single SAR image to successfully geocode the L1.5 CEOS data (the topography is relatively flat in my area of interest), but this isn’t a possibility with the geotiffs.
I see. Sorry to hear that.
Maybe someone else has a suggestion.
Hi @rssg,
I’m not fully familiar with the data you use and your actual use case but I had two ideas while reading your posts. Probably both options are too much work, because you have a lot of scenes or doesn’t work at all. But I wanted to share the ideas anyway.
-
SNAP allows to manually geocode images. You can set ground control points at pixels within a scene where you know the geo-location. You do this a few times spread over the scene and then you can generate a geocoding based on this information.
-
If you have one scene which is geocoded and your not geocoded scenes have the same location and extent you can copy the geo-location information from one to the other. You can create a latitude and a longitude band by Band Maths. These bands can be exported to a separate product. If you have this product you can merge this with you geotiffs. Than you can open the result in SNAP and you can create a pixel-based Geo-coding using these bands.
1 Like
thank you for the suggestion, Marco.
Does the manual geocoding include rubber-sheeting (allow distortions, rotations and higher level transformations) or is it just for linear referencing (define the bounding coordinates of a raster)?
I have never tested it to be honest.
No, unfortunately no rubber-sheet. It just uses polynomials of different order (selectable) to span the grid.
Another option is the GeFolki Co-registration Processor. But I have never used it.
Hi @marpet,
Thanks a lot for your response. I think your 2nd suggestion could work really well in my case. I have both CEOS and Geotiff scenes available for the same location, and with the same extent. I’ll look at creating the latitude and longitude band using the CEOS data after geocoding, and then creating a new product with this band and the geotiff data, as you suggest. I’ll let you know how it goes. Thanks.
Hi @marpet, following your suggestion, I’ve been trying to create a latitude and longitude band for the geocoded image I have using band maths, but there doesn’t seem to be the option to do this within the band maths window for the data I’m using. Could you please let me know the process for doing this?
This image shows the geo-coded data I have available. Do you know if I can use this in some other way to geocode the geotiff scenes that have the same location and extent?
There’s a menu option for opening the ALOS-2 geotiff images, but when I try to use it with my scenes, the image doesn’t load, so I’ve not yet been able to try your first suggestion of manually geocoding the image by setting ground control points.
Thanks!
As long as the product is geo-coded you can create the bands by using the expression LAT respectively LON in the Band Maths.
Ensure you uncheck the ‘Virtual’ option. Afterwards you can create a band subset and store the result. This can then be merged with the products without geo-coding, if they have the same extent.
For the merging, depending who many scenes you have you can do it in the GUI or from the command line.
In the GUI you can open both products simultaneously and then use again the Band Maths to reference the created bands in the product which is not geocoded (I know think that it might be possible skip the first step and directly create the bands in the product without geo-information, but I’m not sure).
On the command line you can use the merge operator. Type gpt -h merge to get help.
You will need to create an XML file and set parameter geographicError to NaN.
A general guide on how to to batch processing is available here:
SNAP Wiki (atlassian.net)
@marpet Thanks, I really appreciate all your help with this.
I’ve added latitude and longitude bands to the already geocoded scene, and I saved it to geotiff format (mosaic_200103.tif) so that it would be in the same format as the ALOS-2 geotiff scene I would like to merge the lat/lon bands with (scene2.tif). I tried using gpt merge, but I get the following error:
The GPT command I’m using is:
gpt merge.xml -SmasterProduct="mosaic_200103.tif" -SsourceProducts="scene2.tif"
The xml file I’m using is: merge.xml (658 Bytes)
Do you have any ideas what I can change to fix this error?
This error occurs in one of the libraries we use. It seems that your geotiff file is not correctly defined, or at least different as the library expects.
I don’t know which of the two causes the problem.
But the exception happens during the reading. So, I think you can’t open it in SNAP too.
You could also try with a different application. If this can open it properly and shows geo-information then it is probably an issue of the geotools library.
A bit strange is you merge.xml file.
When doing merge, the bands of the master are always kept in the result.
I attach two examples. At the top of each file you can find an example command line call.
merge_two_nameless_products.xml (971 Bytes)
merge.xml (768 Bytes)
And maybe you don’t use GeoTiff for the intermediate results. It is better to use BEAM-DIMAP