-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting sharp edges on Cesium when using high resolution DEM #10
Comments
Hello could you read this closed issue |
I just read it. Is it necessary to use your javascript code from the closed issue, because I am using int_16 type of tiff file with 10m resolution. |
Hello, |
Thanks for the info.... I got the desired output. I used Float-32 type of DEM with Big Endian configuration in geoserver and its working fine. But the Int-16 version of same DEM is not working. It seems that there is a problem if we try to use high resolution DEM in 16 bit format. |
That's normal: float-32 type is encoded on 4 bytes for each height and |
Could you send me the new picture? |
thanks that looks good |
I have attached the snapshot of the result that I am getting with 10m resolution DEM (Cartodem-10m). Initially it was Float-32 type(for which I used bil-32 from geoserver), but even after converting to Int-16 type (and using bil-16 from geoserver) same issue is recurring. Also I am getting similar results when I am using SISDP-10m DEM. Currently, I am using Cesium-1.13 and Geoserver 2.8.0.
I referred to this issue(#7) which also consist of mention of similar problem, only in this case, the no. of levels while tiling the DEM seems to be more than sustainable(12-instead of 11). I used 4 levels and 512 x 512 as pixel size while giving the gdal_retile parameters. So, I increased the no. of levels to 11 and pixel size 100 x 100. Although there was reduction in the spikes but issue still remains. Please let me know the correlation between DEM resolution and parameters to be given while performing gdal_retile so that Cesium does not behave weirdly.
Thanks,
Parthesh B.
The text was updated successfully, but these errors were encountered: