# SRTM data represented in 3D using Unity. Problem texturing with sat images

I'm currently working on a project that represents geographic data in 3D using Unity. It basically loads, when given a GPS position, the area around it. For example, given the coordinate 50.5N 6.5E it will load the terrain from 50N to 51N and 6E to 7E. Once the terrain is loaded a texture is applied to the 3D mesh, this texture can be a Landsat image or a Openstreetmap map for example.

I downloaded elevation data (*.hgt files) from NASA’s Shuttle Radar Topography Mission (SRTM). These files have a resolution of 1 arc-second (30m) and contain a 3601 x 3601 matrix of points that represent the height for that coordinate, being the first value of the file the bottom-left coordinate (50N, 6E in my previous example).

To calculate the distance along the longitude between the height points I represent, I apply Haversine's formula (in the file distances between points are not specified). With it I obtain the distance between longitudes for the given latitude, which I can then divide by 3600, obtaining the distance between points.

For Haversine's formula i don't use a fixed value for earth's radius. Depending on the latitude I adjust it between the value at equator and the value at the poles.

For the distance along the latitude its easier since I only have to divide the constant distance (111.2 Km) by the number of points (3600).

Up to here I think that everything is fine and that I have done everything properly. The problem comes now, when applying a texture to the 3D mesh.

To obtain an aerial image of the area I am representing I decided to use Universal Maps Downloader. It allows you to introduce a set of latitudes and longitudes, choose a source (Google Street Maps, ArcGis Online Topography, Open Street Maps...), a level of zoom, and downloads the images of the area as a set of tiles that can be merged into a single image file using the included Map Combiner.

I import this image into Unity and apply it as a texture to the mesh (I don't think that talking about how I adjust the UVs is relevant), and it works, but not perfectly.

The problem is that the texture (call it aerial image or map, as you prefer) doesn't match the topographic data well. Depending on the location I load the image has an offset to the 3D mesh, the direction in which the image is displaced follows no pattern apparently (sometimes a bit to the left sometimes to the right, sometimes a lot, sometimes not much, sometimes up, sometimes down....).

I can adjust it manually adding an offset to the UV mapping, but that is only possible if I have visual references like rivers or coastlines. And since the offset doesn't follow a pattern I can't program my own offset adjustment.

The question is basically: does anyone know where is my mistake or how could I improve my results?

Maybe I'm downloading aerial imagery from the wrong place (and it is not precise) and I should use a different source. So far this option is the only one that lets me obtain images of quality for a given area defined by a set of coordinates in a quite simple and fast way. I couldn't find anything similar.

Maybe I'm doing something wrong when representing the SRTM files.

Perhaps I took a wrong approach from the beginning...

28N, 17W Tenerife and 50N, 6E NRW-Cologne

0N, 6E Sao Tomé and Principe

• I would guess you need to reproject the imagery to match that of the SRS of the SRTM Data. Commented Jan 11, 2017 at 16:19
• SRS? I was trying to make it match by modifying the mapping of the UVs, but that has to be done manually for each "zone" that I load and without reference it is not that accurate. Commented Jan 12, 2017 at 11:25
• What I'm trying to find out is if theres a way of automating that adjustment. Maybe someone came across this problem before and knows if the offset follows some pattern related to the latitude or longitude. Maybe I use the wrong source for imagery and someone recommends a different approach. I thought the problem may be that I'm wrong about the way SRTM data should be represented in 3D, but so far I think it is correct besides a small offset of tops 15m due to the height in the file corresponding to the center of the cells and not the lower-left corner. Commented Jan 12, 2017 at 11:36
• can u please give me some idea regarding how to load SRTM .hgt file data in unity Terrain. Commented Sep 19, 2018 at 9:22

I found the answer to my problem, apparently it is the format of the images I was using. I believe the software I used to retrieve imagery downloads the images with Mercator / Google Maps EPSG: 3875 projection and that that was the problem (can't confirm since it is not displayed within the software). I tried with images in Geographic WGS84 / EPSG:4326 projection using SAS software and they fit perfectly to the 3D mesh I represent. Since I'm new to this I didn't know which projection the 3D data and the images I downloaded were using, or how to match them.

If you wish to create gis data in a game engine such as unity, you can do this with CesiumJS and Google Maps and Blender.

Unity project: https://github.com/NASA-AMMOS/Unity3DTiles

Cesium format: https://github.com/CesiumGS/3d-tiles

You'll need to read this: https://github.com/CesiumGS/3d-tiles/tree/master/specification/TileFormats/Batched3DModel

And to run it offline or airgapped you will need to use docker: https://hub.docker.com/r/geodata/cesium-terrain-server/