Hi,
I tried your script with other dem data. ASTER data, http://gdem.ersdac.jspacesystems.or.jp/search.jsp. I mentioned above. It almost works, can create .terrain files. I load these .terrain files in Cesium, I found some flow here. See screenshot blow. The terrains fall to other at the edge. Could you give any hint about the root cause of this issue?
Thanks,
Shawn
This script almost works. When I run it, I keep getting spikes in my terrain which generally go away as I zoom/pan very close to them. Any ideas on what to do here?
gdal2srtmtiles.py --cesium -z 0-9 -p geodetic srtm_53_07.tif terrain
The spiked terrain is coming about from the lower generated levels (ex: levels 0-8). In Serge’s script to remove the spikes, I commented out the line in generate_overview_tiles:
“dsquery.WriteRaster( tileposx, tileposy, self.tilesize, self.tilesize, dsquerytile.ReadRaster(0,0,self.tilesize,self.tilesize),band_list=list(range(1,tilebands+1)))”.
Of course this gives all the lower level tiles no value so I still need to find out why I’m getting bad values for the lower level/overview tiles.
Hi all. I try fix this problem on second week. Many work and others problems now.
I cant get the script to work
if i run it on a srtm3 (.hgt) file i get an index out of range error
self.open_input()
File “C:\OSM\Cesium\gdal2srtmtiles-join\gdal2srtmtiles.py”, line 937, in open_
input
self.out_ds.SetMetadataItem(‘NODATA_VALUES’,‘%i %i %i’ % (self.in_nodata[0],
self.in_nodata[1],self.in_nodata[2]))
IndexError: list index out of range
if i run it on a tif file i get an file exists error
gdal2srtmtiles.py --cesium -p geodetic N61W008.tif c:\myterrain -z 12
C:\OSM\Cesium\gdal2srtmtiles-join>gdal2srtmtiles.py --cesium -p geodetic N61W008
.tif c:\mterrain -z 12
Generating Base Tiles:
Traceback (most recent call last):
File “C:\OSM\Cesium\gdal2srtmtiles-join\gdal2srtmtiles.py”, line 2593, in <mod
gdal2tiles.process()
File “C:\OSM\Cesium\gdal2srtmtiles-join\gdal2srtmtiles.py”, line 494, in proce
ss
self.generate_base_tiles()
File “C:\OSM\Cesium\gdal2srtmtiles-join\gdal2srtmtiles.py”, line 1552, in gene
rate_base_tiles
os.rename(tilefilename + ‘.new’, tilefilename)
WindowsError: [Error 183] En fil, som allerede findes, kan ikke oprettes
Hi Kevin.
I'm just looking at getting this script up and running, and am getting some filename issues.
Looking at the code it seems we are creating a .terrain file, then creating .terrain.new file, (which we do stuff with), and then finally we try and rename the .terrain.new file back to the .terrain file, which, not surprisingly, fails for us ('Cannot create a file when that file already exists').
Any ideas? We're looking at the area between 1355 and 1385 (line numbers) in the code from the above script.
Also, there was mention of a new script, do you happen to have this?
Thanks
Deirdre.
Hi Deirdre,
I haven’t used the script myself, so I can’t offer much help. Maybe some other folks that have used it can jump in.
Kevin
I had the same issue on Windows.
Somewhere near the line numbers you mention I have this piece of code
# rename files
os.rename( tilefilename, tilefilename + '.old' )
os.rename( tilefilename + '.new', tilefilename )
It works at least if the directory has been emptied before.
There is also a os.remove operation in Python
Arne
Hi,
Agree with Arne. The Script will work if you change line 1552 similar to “os.rename(tilefilename + ‘.new’, tilefilename+‘1’)”. From the screenshot I found the author use Mac, not Windows. Probably that’s the reason of a Windows error (‘Cannot create a file when that file already exists’). I am new to Cesium. My question is how to be used by Cesium after generated the tiles? Kevin, could you give me some instruction? Thanks.
I haven’t used the script, so I’m probably not the best person to answer… but I believe you can just use a CesiumTerrainProvider. Something like:
viewer.centralBody.terrainProvider = new Cesium.CesiumTerrainProvider({
url : ‘http://url/to/the/root/of/your/tile/tree’
});
You’ll need to make sure that the tile tree is either hosted by the same server that hosts the HTML page, or that the tile server includes CORS headers.
Kevin
Yes, im write and test this script on *nix(MacOsx), on windows this script not tested
Here is a brain dump in case someone wants to run with this. I haven’t touched it in months.
I will post what I did to get it to run in Windows and attach Serge’s script which I modified to run in Windows. It will at least give you some usable output. It’s been a while since I ran this so I don’t know if the overview tiles below the highest level are generated to be blank or not. If they’re not blank, you will just get big spikes in terrain which I have not figured out yet. If anyone can fix this it would be greatly appreciated. Our current use is just to write level 8 for the world for example (which works) then we have custom javascript code to ignore all terrain levels lower than that (to avoid problems, blackness, etc).
To run the script:
gdal2srtmtiles.py --cesium -z 0-8 -p geodetic SRTM_NE_250m.tif terrain
note1: this command needs to be run from the GDAL110 (MSVC 2010) command prompt
note2: some sample SRTM data is available here (http://srtm.csi.cgiar.org/). Use the hc.box.net link.
note3: The gdal2srtmtiles script will generate real terrain files for the highest level of terrain(ex: 8) then try to calculate the terrain tiles for all lower levels as “overviews”. This generate_overview_tiles part does not work properly (gives big spikes in
terrain in certain areas) so currently I write all lower levels (0-7) to have zero elevation. This needs to be fixed at some point. A Windows Python debugger is available here (https://code.google.com/p/winpdb/wiki/DebuggingTutorial).
Dependencies to run the gdal2srtmtiles script in Windows:
ActivePython 2.7.2 32bit
GDAL 1.10 32bit MSVC2010
GDAL 1.10 Python 2.7.2 bindings
Numpy for Python
gdal2srtmtiles.py (103 KB)
Hi,
This may be of interest to folks in this thread: I've written a tool for generating heightmap terrain tiles from a gdal data source, very similar in concept to the modified gdal2tiles.py script discussed previously.
https://github.com/geo-data/cesium-terrain-builder
It has a number of known limitations (https://github.com/geo-data/cesium-terrain-builder#limitations-and-todo) and no doubt a lot of currently unknown issues: comments and contributions are very welcome!
Best regards,
Homme
Hi Homme,
Thanks for sharing your work.
I am also interested in terrain generation, and have been experimenting on
it on my free time. I barely scratched the surface of it.
A few questions:
- why using gdal2, which is not released and packaged yet?
- what about using standard c++11 shared_ptr for the podataset?
I will give you more feedback when it get compiled.
BR,
Guillaume
Hi Gillaume,
Hi Homme,
Thanks for sharing your work.
It's a pleasure.
I am also interested in terrain generation, and have been experimenting on
it on my free time. I barely scratched the surface of it.A few questions:
- why using gdal2, which is not released and packaged yet?
GDAL 2 includes the GDAL/OGR unification, which now provides the
`Dataset.Reference()` and `Dataset.Dereference()` methods to GDAL
datasets. This comes in handy when copying dataset handles. Also,
GDAL 2 is the future and I wanted the terrain generation code to work
with it.
I imagine terrain generation is a fairly niche activity and folks will
be able to go to the trouble to custom install GDAL 2 between now and
when it is released. The docker container provided with the package
provides an easy way of getting off the ground for others.
- what about using standard c++11 shared_ptr for the podataset?
I did consider this but thought it better to use the underlying GDAL
dataset referencing functionality for this.
I'm sure, however, the code in general could benefit from migrating to
C++11. The reason I didn't use C++11 features is that g++ marks the
11 standard as experimental (Page Redirection - GNU Project)
and clang potentially requires patches on some systems
(Clang - C++ Programming Language Status), so I decided sticking
to C++98/03 would be more portable, at least for the moment.
I will give you more feedback when it get compiled.
Thanks, I look forward to it.
Best regards,
Homme
Hi Homme,
> - what about using standard c++11 shared_ptr for the podataset?
I did consider this but thought it better to use the underlying GDAL
dataset referencing functionality for this.
Usually, shared_ptr and unique_ptr greatly simplifies error handling by
taking care of releasing the resource automatically (including on
exception).
This is done using a deleter, which can call the unref method, for
example.
I'm sure, however, the code in general could benefit from migrating to
C++11. The reason I didn't use C++11 features is that g++ marks the
11 standard as experimental (Page Redirection - GNU Project)
and clang potentially requires patches on some systems
(http://clang.llvm.org/cxx_status.html#cxx11), so I decided sticking
to C++98/03 would be more portable, at least for the moment.
I have used C++11 in a big project for 4 years.
We sticked with "basics" C++11 features like auto, shared_ptr, locks and threads.
It was working reliably on Debian squeeze and Redhat6 (g++4.4).
You may install an older g++ compiler and have cmake automatically
choose this one to avoid using advanced features by inattention.
Today, Debian, Redhat and Ubuntu all ships implementations with very
good C++11 support (g++ > 4.7). On Macos latest clang is also working great.
It would certainly be less work to use the robust subset of C++11 now
than to rewrite with C++11 later and change your library API.
Best Regards,
Guillaume
Hi Guillaume,
Thanks for the insight: programming in C++ is generally peripheral to
my work 
It sounds like C++11 would work fine, although might need
some CMake finessing to get it working portably. Unfortunately at the
moment I haven't got too much more time to spend on the project.
Regarding the use of `shared_ptr`, as well as setting the deleter to
call Dataset.Dereference(), we'd still have to call
Dataset.Reference() before/during creating the shared pointer.
It would also be nice to standardise on using the C++ interface to
GDAL: at the moment it is a mix of the C and C++.
Best regards,
Homme
Excuse me ,I can't connect to "sergeserver.dyndns.org" ,so I hope you can send your file "gdal2srtmtiles.py" to my email wenwu20082001@gmail.com,thank you very much!
For now I'm using cesium-terrain-builder for producing terrain tiles in .terrain format, but I wonder can Cesium work with float .tif tiles? or do we need to convert .tif tiles to .terrain format anyway?
I can't see any information about this in documentation.
Hello,
You can add terrain in either the quantized mesh or heightmap format. We recommend converting your terrain data to quantized mesh because the performance is generally a lot better than heightmaps.
The Cesium team didn’t create the cesium-terrain-builder, so I’m not very familiar with it’s functionality. However, we plan on including quantized mesh terrain processing support in our upcoming cesium.com application. You can learn more about that here: https://www.cesium.com/
Best,
Hannah