Consider changing the colour and the shape of your pin point in QGIS.
the colour of the pin point is dark, so, if it falls within the dark pixels of your SAR image, you might not be able to see it. Make sure its visible.
(I know that this might sound bit silly )
what happens if you change the CRS of the pins to WGS84 in the layer properties? They are probably stored in lat/lon coordinates while the raster is UTM.
I’m having the same problem, I tried WKT but it doesn’t work in my case.
I vectorized in Qgis a raster file (the selected CRS was always in ESPG32629, WGS84/UTM29N):
In the following we can see at Qgis an RGB base image (Geotiff)
After I exported the vectorized data (shp file) and imported to snap multispectral image:
Then I exported the mask pixels to txt file for later import at Qgis:
When I import the txt file in Qgis, with the same CRS (ESPG32629, WGS84/UTM29N))
The cloud with all the information/pixels are projected to a different CRS (not known, altough at the properties of both layers the txt layer and the raster RGB layer are defined as ESPG32629, WGS84/UTM29N) because they appear in another location different from the RGB raster:
@Abraun
I think I discovered the problem. The mask pixels exported from snap are being exported in wgs84, even though I was working in another CRS at snap. So if I import the txt file with wgs84 CRS and after reproject on Qgis to the main CRS (in this case it was UTM29N), it works.
Maybe this “problem” could be fixed on a future update.
Abraun,
Snap is doing the input correctly, i.e., it uploads the cartesian X and Y projection of UTM for the 29N region and lets you work on that projection:
But when you export the mask pixels, it only export the elipsoidal/geodesic datum wgs84 (lat / lon).
So if I’m correct, we have to reproject everything again, after the snap txt output.
I think at least we should have a warning when we are exporting, but the optimum should be exporting with CRS we are working on (with no warnings).