|
|
|
|
|
|
by qrohlf
1442 days ago
|
|
|
Appreciate the response. One thing I've struggled with in threejs is what coordinate system to use when pulling in data sources. Obviously UTM and lat/lon are inappropriate when you're dealing with a slice of terrain in 3d like this, and from my experience using the 1x1 unit tile dimensions of something like a web maps tile coordinate system does not play nice with ThreeJS at all. Do you just project to Mercator/Web Mercator and then arbitrarily pick something like 1km = 1000 units to work with the data in ThreeJS space, or is there some kind of an established coordinate transform that is commonly used when bringing geospatial data into a non-projected xyz coordinate system? |
|
|
(1) Tile the world in lat/lng. For each tile, turn it into a NxN grid of lat/lngs within the bounds of the tile. Convert each lat/lng/height (where height comes from your DEM) into ECEF XYZ. Texture map imagery onto this mesh.
This works well for a true "globe" but there is plenty of complexity in which tiles and in what detail to load, how well they stitch together (seams), etc.
(2) For the SPS2022 case, I went way simpler. The tile scheme is web mercator (just a plane), where I precalculate which tiles are going into the scene (no loading/unloading logic necessary). Each tile still has a lattice of points, but I simply set the z-value to the height (corrected for Mercator distortion). Then I put part of a sphere over this plane for the atmosphere.
In either case, you will need to be careful about precision issues because ECEF and web mercator coordinates don't really fit in 32-bit floats, although it's close enough if you aren't zooming in too far. You can kind of work around this in three.js by careful usage of the position property of your meshes. Those matrixes get combined in three.js in javascript with doubles.