Best practices for obtaining real world lat, long, height, and converting that into UE4 coordinates

The fundamental issue I’m trying to solve is that I want to place lots of objects on the earth according to known longitude, latitude and height data.

As a test, I picked an arbitrary point with a known elevation, because finding lat and long seems easy. In my test case I picked Guadalupe Peak in Texas. I went to bing maps and I found the longitude and latitude. I figured bing was a safer than google maps, because that’s what Cesium uses right? So I got the latitude and longitude values of 31.891330 and -104.861100 respectively.

Then I went to wikipedia and found the height. The listed height is 2667 meters.

So what I did was a made a simple actor who’s parent class was CesiumGeoreference. I added a sphere to it and then in the construction script I did this:

I find the CesiumGeoreference on which the world is based. From it, I call the Inaccurate Transform Longitude Latitude Height to UE node with the values above to generate an xyz position (note in the node it’s long then lat). Then I set the actor’s position to that xyz value. I visually set the origin (red sphere) to where I thought the peak was. The white sphere is where the above blueprint set the sphere. All things considered, it’s pretty close, but I was hoping to get dead on accuracy.

from the side

from the front

I think there’s something else going on though, because if I manually type in the latitude and longitude that I got from bing, with the height I got from wikipedia into the world’s cesium georeference, for where the center is, they are almost exactly in the same spot, but it’s the same wrong spot. The red sphere moves to where the white sphere is, now both of them are not in the right spot.

This makes it seem like the data I got, or the map data is incorrect. It’s safe to say that Cesium isn’t the problem right? I checked the lat/long against google maps, and it’s only ever so slightly different. The height of 2667 meters is listed in multiple places. So I think my numbers are ok. I realize the node has Inaccurate in the name, but I’m hoping it’s the centimeter inaccuracy, not the dozens of meters inaccuracy. Also, it doesn’t make sense that when I recenter my world according to my lat, long, and height numbers, that they’d match so closely. Anyways, I’m left scratching my head. I’m sure I did something dumb, so hopefully someone can point me in the right direction. I tried to be as transparent as possible with my approach, and I’m happy to provide clarification where it’s still needed.

Sorry for the massive post! Thanks in advance.

Hi @nbaja,

This is a very common problem. When you look up a height on Wikipedia and elsewhere, it’s almost always a height above sea level. “Sea level” is a bit of a fuzzy concept. It’s made concrete (at least a “mean” sea level is) by various geoid models, but geoid models are messy and irregular. Instead, Cesium uses heights above the WGS84 ellipsoid. This is a nice mathematical approximation of the Earth’s shape, used by GPS and many other things. This definitely doesn’t mean Cesium is inaccurate or otherwise compromising here. But, as always with geospatial data, it’s necessary to keep the coordinate system of your data in mind. A height expressed relative to WGS84 will be different by roughly tens of meters from a height expressed relative to mean sea level. I say “roughly tens of meters” because it’s different in different parts of the world.

Long story short, you need to compute the difference between WGS84 and MSL and add that to your height from Wikipedia. You can use an online calculator like this one:

Put in your latitude and longitude of interest. You can just set the “GPS Elevation” to 0. Hit Submit. Then add the displayed “Geoid Height” value to your height from Wikipedia. The value is -23.765 in this case, so you’ll be subtracting about 24 meters.

I don’t know if this will put your Actor precisely on the peak, but it should be much closer.


1 Like

Hi @Kevin_Ring,

Thank you for explaining this to me. I was not aware of this thing with sea levels, and that website is a great resource.

As far as latitudinal or longitudinal variation, is this just something I’m going to have to live with? I did a few more tests and using this method, and my latitude, longitude differences are still there, though of course from a global scale, they’re very minor. For example, I did this with Mount Rainier and if I compare where my sphere appears, vs where the actual peak of the mountain is, the latitude difference is only -0.000016 and the longitude difference is only 0.000088. Using the website you mentioned, this gets me very close here. It’s less close in other places, but overall, everything seems like it’s within 10 meters in every direction.

This is the difference in cm, which is not at all bad. I just want to make sure that I’m getting the best results I can.

I think you’re running into limitations of Blueprints and the “Inaccurate” transform. The reason it’s inaccurate is because, like all of Blueprints, it only deals with single-precision floating point numbers. That means that you get about 7 significant digits. For a longitude or latitude with 2-3 digits out front of the decimal point, that leaves you 4-5 after the decimal point. That looks like approximately the precision you’re achieving.

To place things more precisely, add a CesiumGeoreference component to your Actor. The “Placing Objects” tutorial explains how to do this:


A red flag I saw here was the longitude in your bing maps image being -104.861100 - those last two places zeroed could lose up to ~10 m in that axis alone.

As the surrounding longitudes do show 6 decimals places, this is a telltale sign that the landmark’s position might have been generated via a different means with its own inaccuracies - e.g. GPS on phone where photos were taken, as where you clicked was indeed a photo point. You’ll see below another landmark indicated for the peak 37m away. In other words, the peak isn’t necessarily at that lat/lon.

Of course the peak could have been at a longitude of exactly -104.861100, but you’ll also note another photo point just to the north - same sort of precision issues. (The longitude here isn’t accurate to 6 decimal places despite how it looks, that’s just how -104.867 gets represented in single precision floating point.)