Re: [Qgis-user] vector point grid to raster grid -- pixel size does not work SOLVED
Hi, I had some intensive learning during the last days, and thanks again for your help. After all it turns out that it is something Nicolas wrote, it is a matter of the projection. The Japanese software just exported to a projected format, but the original data seem to be in lat long. I found a way to get the unprojected data and now can create a beautiful hillshade in an unprojected lat long layer. And it even looks good in a projected project (EPSG:6670) with on the fly projection. For hydrological analyses I need to use the projected data, but the artifacts do not matter here. While binge-watching YouTube videos I realized that these artifacts occur with the pros as well when they use the projected layers for their analyses. Now everything much better and "in place". Best, Maria > Am 15.05.2020 um 13:21 schrieb Nicolas Cadieux : > > > > Nicolas Cadieux > Ça va bien aller! > >> Le 14 mai 2020 à 23:12, Nicolas Cadieux a >> écrit : >> >> Hi, >> >> >> See below for comments. >> >> Nicolas Cadieux >> Ça va bien aller! >> >>> Le 14 mai 2020 à 22:21, Priv.-Doz. Dr. Maria Shinoto >>> a écrit : >>> >>> Hi again, >>> >>> and sorry for the ongoing discussion. >>> >>> Today I exported a selection of the DEM data to a shapefile, just 9MB for >>> the main file, and this makes testing very fast. >>> >>> (A) TINs did not work. >> >> TIn interpolation has memory problems with large data sets. Same problem >> since QGIS 2x at least. It was cool features but is not made to handle >> today’s data sets. >>> >>> (B) I tried all steps carefully again, but even the GDAL raster is horrible >>> now. >>> >>> Here are some screenshots with my explanation and the protocol for >>> rasterization and filling nodata. >>> >>> It seems that the artifacts are due to no data fields that evolve during >>> rasterization as a pattern. These nodata fields may be due to a slight >>> inclination of the grid from the export of the data with the Japanese >>> software. >>> >>> 1) The point grid, one can see the inclination >>> >> <01.jpeg> >>> >>> >>> 2) The raster of the same area, one can see the points of the vector point >>> grid along the white empty space; this is NODATA. >>> >> <02.jpeg> >>> >>> >> I would use gdal_grid not rasterize. Use Gdal grid with a larger search >> circle will solve this problem. Use nearest neighborhood with a search >> radius larger than the pixel (like 7m). That will reduce the no data. Click >> on the help or go to the gdal website. That will help you add the missing >> parameters like the -txe and -tye. (The extent) and the -outsize for the >> number of pixels. >> >>> I add the protocol >> <2020-05-15-rasterize-protocol-for-selection.txt> >>> >>> >>> >>> 3) Using the Fill NODATA from the Raster menu makes a beautiful looking >>> raster, there seem to be no flaws. >>> >> <03.jpeg> >>> >>> >> >> That fixes things but adds new data to the raster. This may be unwanted. >> >>> I add the protocol. >>> >> <2020-05-15-fill-nodata-protocol-for-selection.txt> >>> >>> >>> 4) This is the same area as in (3), but instead of a pseudocolor ramp shown >>> as hillshade. >>> >> <04.jpeg> >>> >>> >> This is normal if you select a bad z factor (probably not the case here). >> You will have the same thing if you zoom in and have nearest neighbour in >> the “zoomed in” under “resampling“ in the hillshade symbology window. >>> >>> 5) This is the impression from a larger area. >>> >> <05.jpeg> >>> >>> >>> >>> 6) This is the same small area hillshaded with the GDAL tools. Looks good, >>> but suffers from the same artifacts. >>> >> >> No this is way it should look like (Image under). You can see the pixels >> because you are zoomed in. Again, select the correct z factor (if x,y are >> in long -lat and z is in meters or feet.) (probably ok here). >> >> <06.jpeg> >>> >>> >>> >> Play with the resampling zoomed out parameters in symbology >> >> >>> 7) The larger area from hillshade in GDAL tools. >>> >> <07.jpeg> >>> >>> >>> >>> >>> >>> I sorry to be so insisting on the problem, I think it is not the problem of >>> QGIS, but perhaps there are solutions to such a case. -- The projection is >>> OK, and the base map fits perfectly. >>> >>> Best and Thanks to anyone trying to help, >>> Maria >>> >>> >>> >>> ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] vector point grid to raster grid -- pixel size does not work SOLVED
Nice to know you got it! Nicolas Cadieux Ça va bien aller! > Le 16 mai 2020 à 06:13, Priv.-Doz. Dr. Maria Shinoto > a écrit : > > Hi, > > I had some intensive learning during the last days, and thanks again for your > help. > > After all it turns out that it is something Nicolas wrote, it is a matter of > the projection. The Japanese software just exported to a projected format, > but the original data seem to be in lat long. I found a way to get the > unprojected data and now can create a beautiful hillshade in an unprojected > lat long layer. And it even looks good in a projected project (EPSG:6670) > with on the fly projection. > > For hydrological analyses I need to use the projected data, but the artifacts > do not matter here. While binge-watching YouTube videos I realized that these > artifacts occur with the pros as well when they use the projected layers for > their analyses. Now everything much better and "in place". > > Best, > Maria > > >> Am 15.05.2020 um 13:21 schrieb Nicolas Cadieux >> : >> >> >> >> Nicolas Cadieux >> Ça va bien aller! >> Le 14 mai 2020 à 23:12, Nicolas Cadieux a écrit : >>> >>> Hi, >>> >>> >>> See below for comments. >>> >>> Nicolas Cadieux >>> Ça va bien aller! >>> Le 14 mai 2020 à 22:21, Priv.-Doz. Dr. Maria Shinoto a écrit : Hi again, and sorry for the ongoing discussion. Today I exported a selection of the DEM data to a shapefile, just 9MB for the main file, and this makes testing very fast. (A) TINs did not work. >>> >>> TIn interpolation has memory problems with large data sets. Same problem >>> since QGIS 2x at least. It was cool features but is not made to handle >>> today’s data sets. (B) I tried all steps carefully again, but even the GDAL raster is horrible now. Here are some screenshots with my explanation and the protocol for rasterization and filling nodata. It seems that the artifacts are due to no data fields that evolve during rasterization as a pattern. These nodata fields may be due to a slight inclination of the grid from the export of the data with the Japanese software. 1) The point grid, one can see the inclination >>> <01.jpeg> 2) The raster of the same area, one can see the points of the vector point grid along the white empty space; this is NODATA. >>> <02.jpeg> >>> I would use gdal_grid not rasterize. Use Gdal grid with a larger search >>> circle will solve this problem. Use nearest neighborhood with a search >>> radius larger than the pixel (like 7m). That will reduce the no data. >>> Click on the help or go to the gdal website. That will help you add the >>> missing parameters like the -txe and -tye. (The extent) and the -outsize >>> for the number of pixels. >>> I add the protocol >>> <2020-05-15-rasterize-protocol-for-selection.txt> 3) Using the Fill NODATA from the Raster menu makes a beautiful looking raster, there seem to be no flaws. >>> <03.jpeg> >>> >>> That fixes things but adds new data to the raster. This may be unwanted. >>> I add the protocol. >>> <2020-05-15-fill-nodata-protocol-for-selection.txt> 4) This is the same area as in (3), but instead of a pseudocolor ramp shown as hillshade. >>> <04.jpeg> >>> This is normal if you select a bad z factor (probably not the case here). >>> You will have the same thing if you zoom in and have nearest neighbour in >>> the “zoomed in” under “resampling“ in the hillshade symbology window. 5) This is the impression from a larger area. >>> <05.jpeg> 6) This is the same small area hillshaded with the GDAL tools. Looks good, but suffers from the same artifacts. >>> >>> No this is way it should look like (Image under). You can see the pixels >>> because you are zoomed in. Again, select the correct z factor (if x,y are >>> in long -lat and z is in meters or feet.) (probably ok here). >>> >>> <06.jpeg> >>> Play with the resampling zoomed out parameters in symbology >>> >>> 7) The larger area from hillshade in GDAL tools. >>> <07.jpeg> I sorry to be so insisting on the problem, I think it is not the problem of QGIS, but perhaps there are solutions to such a case. -- The projection is OK, and the base map fits perfectly. Best and Thanks to anyone trying to help, Maria > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user