Nicolas Cadieux Ça va bien aller!
> Le 14 mai 2020 à 23:12, Nicolas Cadieux <nicolas.cadi...@archeotec.ca> a > écrit : > > Hi, > > > See below for comments. > > Nicolas Cadieux > Ça va bien aller! > >> Le 14 mai 2020 à 22:21, Priv.-Doz. Dr. Maria Shinoto >> <maria.shin...@zaw.uni-heidelberg.de> 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
