Hi folks,
I started to work with S-2 MAJA processed data.
My workflow:
Bands extractor to only keep 10 bands (Flat reflectance) + cloud mask
Resampling the 20m bands
Reprojecting to local CRS
I would like to export the result as geotif but all the bands in seperate files.
So it is somehow like the MUSCATE original format.
So far I have not figured out how to do this. Export Geotif only produces mulitlayer raster.
Thanks for the help
I think this Thread can help you:
Are you very sure you have to use GeoTIFF? Exporting data from SNAP has a section on direct use of BEAM DIMAP products.
Thanks Marco,
it took me a while, but the split seems to work now =).
I do a reprojection to EPSG 25832 and than a subset.
After drawing a polygon in QGIS (25832) I imported it to a reprojected scene and took the WKT from the image window.
Now the reprojected scene doesn´t fit to the original polygon after imported back into QGIS.
Is it better to subset with a polygon drawn in WGS84 and before reprojection?
Thanks again…you are a great help to a lot of us
Christian
Hi George,
I want to put the resulting data into a data cube. Therefore I have choosen GeoTIFF.
Thanks for the thoughts
Christian
when you have taken the WKT from the reprojected scene then it is okay to do the subsetting after the reprojection.
It should also be fine if you take the WKT from the original S2 scene, which is in UTM CRS. Then doing the subsetting first and then the reprojection. Sure, both will lead to different results but should be -somehow- in line with the original polygon.
In both cases the subsetting is using the bounding box of the polygon.
Right now, I can hardly imagine what the difference between the processing result and the expected polygon is. Can you provide some images?
In terms of performance, it doesn’t matter much in which order you do the subsetting. Because it is only processed what is written to the output. Doing the subsetting first might be a bit faster.
To me, “data cube” is just a 3-D array. Older software may only support GeoTIFF, some newer software won’t make a data cube from heterogeneous 2-D images because the metadata support assumes consistent scaling, units, etc. for all cells. Newer software may call a heterogeneous data cube a “stack” and preserve metadata for each layer.
Hi again,
I tried a to find a suitable workaround.
Unfortunately I can´t get resulust near to the quality I need them.
Polygon with original image in QGIS.
Poygon with subset image from snap
some rough messurements to get an impression about the dimensions
so far I have not figured out why SNAP is not subseting correctly.
Maybe it is not the best tool to do the subsets?
Many use the subsetting on S2 data and they are happy with the results. So, in general it works quite well.
You could try to create the polygon in SNAP or describe your process in more detail. Share the polygon and mention the name of the product you are using. Maybe there is a mittle mistake somewhere.
Thanks Marco, I really appreciate your help. Yes I also think there must be some mistake but I can not
find the bug.
The WKT - Polygons I use are seven tiles in EPSG:32632
PF_SHCUBE_32632.shx (108 Bytes)
PF_SHCUBE_32632.shp (236 Bytes)
PF_SHCUBE_32632.prj (400 Bytes)
PF_SHCUBE_32632.dbf (311 Bytes)
ME
MULTIPOLYGON (((7.486660270343582 54.08395946173686, 9.052055565321655 54.09346550016721,
9.050934795594888 53.17304645967608, 7.5192282156715065 53.163852982293214,
7.486660270343582 54.08395946173686)))
MF
MULTIPOLYGON (((7.456526852507054 55.00396488934096, 9.057549576918804 55.01374091761429,
9.05626844112798 54.093463604029864, 7.490870721780319 54.08401235561628,
7.456526852507054 55.00396488934096)))
MG
MULTIPOLYGON (((7.420167969623268 55.92376217710197, 9.05890592419506 55.9338781613061,
9.057549576918804 55.01374091761429, 7.456526852507054 55.00396488934096,
7.420167969623268 55.92376217710197)))
NE
MULTIPOLYGON (((9.05626844112798 54.093463604029864, 10.621596588784532 54.08254884020609,
10.586701221780693 53.162488730787494, 9.055056967208872 53.17304462589779,
9.05626844112798 54.093463604029864)))
NF
MULTIPOLYGON (((9.057549576918804 55.01374091761429, 10.658497192484008 55.002451096023506,
10.621596588784532 54.08254884020609, 9.05626844112798 54.093463604029864,
9.057549576918804 55.01374091761429)))
PE
MULTIPOLYGON (((10.621596588784532 54.08254884020609, 12.184922090137954 54.05129797495987,
12.116486514470367 53.132264378788754, 10.586701221780693 53.162488730787494,
10.621596588784532 54.08254884020609)))
PF
MULTIPOLYGON (((10.658497192484008 55.002451096023506, 12.257282934994945 54.97012752042874,
12.184922090137954 54.05129797495987, 10.621596588784532 54.08254884020609,
10.658497192484008 55.002451096023506)))
PE_SHCUBE_32632.shx (108 Bytes)
PE_SHCUBE_32632.shp (236 Bytes)
PF_SHCUBE_32632.prj (400 Bytes)
PE_SHCUBE_32632.dbf (311 Bytes)
NF_SHCUBE_32632.shx (108 Bytes)
NF_SHCUBE_32632.shp (236 Bytes)
PF_SHCUBE_32632.prj (400 Bytes)
NF_SHCUBE_32632.dbf (311 Bytes)
NE_SHCUBE_32632.shx (108 Bytes)
NE_SHCUBE_32632.shp (236 Bytes)
points.prj (145 Bytes)
NE_SHCUBE_32632.dbf (311 Bytes)
MG_SHCUBE_32632.shx (108 Bytes)
MG_SHCUBE_32632.shp (236 Bytes)
PF_SHCUBE_32632.prj (400 Bytes)
MG_SHCUBE_32632.dbf (311 Bytes)
MF_SHCUBE_32632.shx (108 Bytes)
MF_SHCUBE_32632.shp (236 Bytes)
PF_SHCUBE_32632.prj (400 Bytes)
MF_SHCUBE_32632.dbf (311 Bytes)
ME_SHCUBE_32632.shx (108 Bytes)
ME_SHCUBE_32632.shp (236 Bytes)
PF_SHCUBE_32632.prj (400 Bytes)
ME_SHCUBE_32632.dbf (311 Bytes)
The data I would like to work with is Sentinel-2 MAJA processed Data from EOC Geoservice.
MAJA_Products_Description.pdf (565.1 KB)
https://download.geoservice.dlr.de/S2_L2A_MAJA/
Regards
Christian
I found what is causing the issue.
Have a look at the following image:
Actually, we already have an issue for this.
[SNAP-721] Allow map coordinates for specifying the bounds of a subset - JIRA (atlassian.net)
Hi Marco,
this is very interesting.
To get a better understanding…
…if I open a MAJA original product in SNAP, it comes projected in EPSG:32 632 from DLR,
does SNAP get this information about the projection from the metadata-file?
Or does the Software assume every opened product is in EPSG:4326?
What would be a smart workaround?
To transform all the 7 polygons in QGIS into EPSG:4326.
Load the MAJA product and also transform it into EPSG:4326
Do the substet and transform it again into the EPSG:25832, what is the preferd CRS for the final product?
It sounds like lots of transformations.
Can you think of anything smater?
Regards Christian
…just forgot. My main point I would like to achive is to have 7 non overlapping tiles with no gaps.
You could look up the corner coordinates in pixel of the non-overlapping pixel for the tiles. Using the pixel-coordinates the subset should work.
If the tile is not at a UTM zone border the coordinates are constant for all tiles.
The overlap is 10Km. So, in 10m resolution you need step into the 1000pixels. For 20m resolution 500 pixels.
At UTM borders you need to look up the coordinates. Here the coordinates can vary.
Hi Marco, it took me a while to figure out the exact pixel position to do the subset for all seven tiles. But in the end it seems to work =) . The result from SNAP is the same as the cliped subset from QGIS. Thanks for the support.
Another thing came to my attention.
A safed graph with resampling does not keep the information.
So when bulk processing is started the CRS has always be changed again (in my case EPSG25832).
If forgotten the transformation is not correct as SNAP uses WGS84.
Is there a reason why individual changes are not kept during saving?
Regards
Christian
I’m not often using the Graph Processor and the Bulk Processing. I usually use the command line.
In general, the parameter should be saved with the graph.
I also see little logic in this. Can’t think of an explanation at the moment, sorry.
Hi guys…a little different topic but still the same project. So I keep it in this discussion rather than opening a new one.
I saved my processed data.
Graph looks as follows:
so
Now if I open the processed product and the raw data from DLR I get a significant difference in the grey-value-range.
The original MAJA product is surface reflectance x 10000. so the raw product with a range from 0-16798 seem okay.
But my processed product from SNAP with -0,3125 - 2,1858 seems akward…
Do I missunderstand something…maybe someone with a litte more experience can clear this up a little…would be greatful for some input.
Cheers
Christian
For me it seems that these are the scaled values.
In the Geotiffs you have created, the actual reflectance values are stored and not the raw values.
Does the value range fit to the Maya data when you open it in SNAP?
Reflectance_SNAP.pdf (102.0 KB)
Hi Marco,
I did some testing with the data.
Reason for the difference seems to be the MUSCATE importer in SNAP.
(see pdf - the created geotiffs and the raw data imported via the MUSCATE-importer have same value range…same as in QGIS)
This is the reason why values are changing.
But still I can´t see why it is shifting the reflectance into negative values.
Is there any documentation what the MUSCATE importer is doing and why the overall range is changeing? The product description from MAJA only tells me that the values are surface reflectance multiplied by 10000.
Cheers Christian
