The artefact in terrain tiles

[michaelchin]

My name is Michael Chin. I am working at the EarthByte Group of Sydney University. Recently, we are building a Cesium application with terrain data. We found your Cesium Terrain Builder on GitHub, which is great. Thank you very much for creating such a useful tool. However, when we put the terrain data into Cesium, we noticed something is not very correct along the boundary of terrain tiles. Please see the screenshot below. It seems the overlap pixels are not very right. We are wondering if you could help us with this. Thank you very much.

On one side, there is a rainbow wall. On the other side, there is a colourful line above a transparent wall. If you look down from above, there is a black line along the terrain tile boundary.

[michaelchin]

The problem can be reproduced by using TrueMarble.32km.1350x675.tif, which can be downloaded from http://www.unearthedoutdoors.net/global_data/true_marble/download. We are not using this raster. Our raster(DNSC08BAT_2min_rs.nc) is too big to be attached here.

And it seemed that the number of files/folders created is incorrect for global map(-180, 90, 180, -90). For example, on level 0, according to https://cesiumjs.org/data-and-assets/terrain/formats/heightmap-1.0.html, there should be two folders with one file in earch folder. But the terrain build created 3 folders with 2 files in each folder for me. The problem can be workarounded by changing the map to (-180, 89.99, 179.99, -90). The black gap is always there no matter I apply the workaround or not.

I am guessing maybe the black gap is because the rightmost tiles need to overlap the leftmost tiles in a global map.

[michaelchin]

We were using docker https://registry.hub.docker.com/u/homme/cesium-terrain-builder/

[homme]

Thank you for the comprehensive bug report. I have only used CTB for small areas and not global datasets, so you are a traversing new territory! I have a feeling that your guess that the gap is to do with a problem with the overlaps at the antimeridian is correct. The first place in the code to investigate is this function.

Are you using ctb-tile to generate both the overlay imagery tiles as well as the terrain tiles or do the overlay tiles come from a different source? If the imagery tiles are also created by ctb-tile there is a chance that the problem is manifested in both output tilesets.

I am guessing you are visualising the new gravity model from the Cryosate-2 data? If so cool!

I am busy preparing for a week abroad next week so unfortunately will likely not be able to look into this problem before my return. If you are keen to get it prioritised then we are open to getting the work funded and, of course, will gladly accept code contributions.

[michaelchin]

Thanks Homme. We were using gdal2tiles.py for imagery tiles, which is working fine. We only used ctb-tile for terrain tiles.

Yes, we are visualising the new model in the recent Science paper. Here is the link if you are interested http://portal.gplates.org/cesium/. Currently, we are using the terrain data from http://www.vr-theworld.com/. But it does not suit our purpose very well. We need to use our own terrain data instead. I think the ctb-tile is very good. Once we fixed the "black gap", we will switch to our own terrain tiles.

[homme]

@michaelchin Are you able to use the latest version of master (commit ba59bba238de8bbc5f607b3f56e647a9b2783b2f at the moment) to check whether the "black gap" problem has been resolved? There have been a couple of changes committed recently which may fix that particular issue. If it has not been resolved are you able to provide a minimal DEM dataset which replicates the problem?

The issue of there being three directories created under the top level 0 folder is a separate problem, and fairly harmless. As you found out it is caused by a very slight overlap across the date line and/or poles. Cropping the DEM to be absolutely no greater than -180, 90, 180, -90 should solve the problem.

[homme]

I've just remembered you are using the docker image, in which case doing a docker pull homme/cesium-terrain-builder should provide you with the latest code.

[michaelchin]

Thanks Homme. I will try it later. A project review meeting is coming soon. I am quite busy right now.

[ethan0911]

@michaelchin @homme I met the same issue. Have you solved the issue? I try to develop a server to visualize the bathymetry data. There is something wrong with the visualization outcome. The seabed is higher than the land. Do you know why? I don't know if Cesium works well on visualizing terrain underwater.

[michaelchin]

@ethan0911 I am pretty sure that the Cesium can handle negative height data(seabed). Here is a working example http://portal.gplates.org/cesium/?view=topo15 . I think you might want to check your terrain data. It seems to me that your seabed height is not negative. Is it possible you are using unsigned integer?

[ethan0911]

@michaelchin thank you for your reply. yeah, your work inspires me. I used the bathymetric data which can be accessed http://www.marine-geo.org/tools/GMRTMapTool/. I test with this terrain tile:

it shows that the altitude in the sea is negetive when I load the data in QGIS. However, I also try to debug and inverse the raw data. Here is the result:

it seems that the visualization of seabed is correct. However, there are lots of gaps on the land. Do u know any possible reason?

[ethan0911]

@michaelchin you mean the data value in the raw tif is unsigned integer? May I use your terrain data to test the code? the link [http://www.unearthedoutdoors.net/global_data/true_marble/download] doesn't work.

[ethan0911]

@michaelchin I check the source file. I found that @homme use uint16_t to store the height. I wonder if the integer is cast to unsigned integer? types.hpp typedef uint16_t i_terrain_height; ///< A terrain tile height

TerrainTile.hpp protected: /// The terrain height data std::vector mHeights; // replace with std::array in C++11

[michaelchin]

@ethan0911 I am using the grid from here ftp://topex.ucsd.edu/pub/srtm15_plus/. If the height data is stored in uint16, there might be a problem. The original problem in this ticket is due to the overlap pixel at the boundary of tiles. If you have time, I suggest you read this paper http://journals.plos.org/plosone/article?id=10.1371%2Fjournal.pone.0150883 . The technical details are in the supplementary section. I ended up using my own scripts to create the tiles to suit my purpose.

[ethan0911]

@michaelchin May I talk to on hangout?

[michaelchin]

@ethan0911 The work has been done more than one year ago. I can hardly remember any details. I don't think it would be effective to have a talk because it is very likely that I have to check the paper each time you ask me something. I have written down everything in the paper. And it might take weeks to have everything sorted out.

[jonaszhang]

@ethan0911 I meet the same problem with you. I used the data from ftp://topex.ucsd.edu/pub/srtm15_plus/ provided by @michaelchin and created the terrain tiles using the script athttp://journals.plos.org/plosone/article?id=10.1371/journal.pone.0150883 . Have you resolved this issue? If so, would give me some help?

[ethan0911]

Hi, I solved it by modifying the readheightmap function. I can't remember the specific name. Cesium read the height data into a unit16 type. it works well when changing the uint16 to int16.

Best Ethan

在 2017-10-03 17:34:36，"jonaszhang" notifications@github.com 写道：

@ethan0911 I meet the same problem with you. I used the data from ftp://topex.ucsd.edu/pub/srtm15_plus/ provided by @michaelchin and created the terrain tiles using the script athttp://journals.plos.org/plosone/article?id=10.1371/journal.pone.0150883 . Have you resolved this issue? If so, would give me some help?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.