I would first like to thank you all for the precious support that is provided in this forum. I have recently started working with EO, and I am doing my really first attempts with S1, aiming at mapping sea wind flow fields. Before creating this topic I’ve tried to find some similar issues, but I could not find any solutions.
I have problems processing OCN products. I would like to investigate sea wind fields, so I started taking advantage of the OCN products, which should provide already processed information about wind speed and direction. Everything seems to have a proper sense when importing files in SNAP. Wind data, already in m/s, are correctly disposed and the useful “worldwind analysis view” is working fine, as you can see in the screenshot.
Geographical information of the wind flow field are basically some kind of “upside-down”. So, I go back to the SNAP tool, trying to implement some geometrical terrain correction, but unfortunately, it seems that this is not possible:
I can confirm that exporting the wind vector as shapefile did not work for me either. As a test, I opened the table in SNAP, select all entries (Ctrl+A), then inserted them into an empty text file (here export.txt) and read it as a delimited text into QGIS.
Thanks a lot Andreas. That was a nice check. I’m kind of struggling because I realize the power of the OCN product results, but being unable to use them is kind of frustrating
I had the same thought. I don’t want to be rude or to judge other people work, but I’m feeling like this tutorial is kind of wrong. The results are showing wind vectors on the land. It should be impossible, since the measurement are clearly sea-based. Hence, I think that, as you said, it has been ignored. What a pity.
We have seen very few OCN product users on these forums - good to see that you are here, let’s try to fix the issues and define recommended processing chains for OCN product processing.
@mengdahl Thanks a lot! By the way, I’ve just tried to play around my issue and apparently now things are fine. This is the process I’ve carried out:
Export from SNAP the shapefile
Import the .shp in QGIS
From the .shp layer in QGIS, I export the correspondent .csv file
I re-import the layer, now using the option “import from delimited text” as @ABraun has done before. The only difference is that I’m now importing the .cvs file that I generated in the step n.3, from QGIS, and not the copy-paste from SNAP.
The result is great now. Anyway, it’s not a smooth process, and to me it looks like a trick. I’m trying to figure out what’s the issue. Could it be something related to the reference system? That’s because, when importing from an external text, QGIS let you select the RS (and I’ve used WGS 84). Any other ideas? @ABraun Could you try with your wind field as well?
Still, I don’t get why the coordinates from the table are incorrect and then turn out to be correct after re-importing as CSV.
A direct SHP export from SNAP would be nice and I think it’s already quite nearly achieved.
It looks like SNAP extract locations of measurements both :
as longitude and latitude (from the owiLon and owiLat variables provided in the OCN product)
as wkt geometry like POINT(-6.0791… 54.6164), but it is difficult to say how it is computed here as this location does not match the one of longitude and latitude above.
The discrepancy between the two set of position appear clearly on one of your snapshot.
On your first attempt, while exporting in Shapefile, SNAP is using the wkt geometry so as to record the geographic location (the wrong one), and adds the remaining data as attribute of each position. Thus the geometry is not good, while the attribute is fine.
Then in QGIS, when you export an shp layer in QGIS as CSV, it actually does not export the geometry, but only the table of attribute. However the metadata contain owiLat and owiLon that is correct (see previous point).
Then when your reopen it with QGIS, it selects the geometry definition as point coordinates associated to owiLat and owiLon, based on assumption on the names, and it is working fine.
This fully explains why the display is first incorrect then correct.
This confirms as well that there is an issue with the computation of the geometry of each point in OCN products within SNAP.
I had the same problem and after using the .csv method this seems to work. However, that is quite frustrating since the “World wind analysis view” and “World Map” correctly locate the image. It seems that it comes from a wrong reading of the data in the explorer. Did you found a method to correctly apply the coordinate, not only for the vector files, but also for the wind raster?
Anymway, thank you all for your interest in the subject.
Hi @RomainJatiault. No, I did not find any other method besides the one already posted here. Thanks a lot to you for your interest. If in the meanwhile you managed to have some results with your rasters then let us know
