[OSM2World] Understanding the offset in the ENU frame

Julien JPK julienjpk at email.com
Mon Mar 19 10:39:15 UTC 2018


Hello,

I am currently using OSM2World for some work, and have bumped into a 
small issue which I can't seem to be able to understand... I have a 
feeling this is because I'm missing something as to how OSM2World works 
internally, so I thought I'd ask here.

I use OSM2World in order to generate simple (roads and buildings) OBJ 
models from OSM data. In order to do so, I put the OSM file through 
osmfilter to remove superfluous entities, and then into OSM2World with 
the following settings:

createTerrain = false
renderUnderground = false

OSM2World does generate the model the way I need it, but the (x,y,z) 
coordinates of my OSM nodes in the ENU frame are off by a small margin 
which is a bit inconvenient in my case. Let me give you an example.

Let's take the City of London, with bounding box (51.50687,-0.11382) to 
(51.52332,-0.07273). Based on what I've seen in OSM2World's code, the 
origin for geodetic to ENU projection should be at the centre of the 
box, that is (51.515095,-0.093275).

Now let's take a building way node in that box, say 373607295, the 
south-east corner of the London Stock Exchange.

https://www.openstreetmap.org/node/373607295

Its OSM coordinates are (51.5147463, -0.0985846). With no elevation, the 
ECEF coordinates for that point should be:

(3977358.5306913713, -6843.552702974673, 4969383.616620987)

Which, in the ENU frame centered on our origin, is:

(-368.58236792647006, -38.782337452820734, -0.010746002829179702)

However, if I have a look at the OBJ model in Meshlab and fetch the 
(y-forward, z-up) coordinates of that building corner at ground level, I 
get:

(-367.822998, -38.817001, 0.000000)

Which means OSM2World has offset my point by:

(-0.7593699264700717, 0.03466354717926379, -0.010746002829179702)

Now of course, that delta is rather small, but in my case it turns out 
to be rather inconvenient.

My guess is that OSM2World does more than just a standard geodetic to 
ENU conversion, which might explain the offset. Or maybe it adjusts the 
origin or the bounding box to fit entities more confortably. If that's 
the case, I'd like to know more about it, so I can replicate that 
behaviour and match the model (or just apply the opposite operation on 
the OBJ file if possible).

Any clues as to where I could find a reason for the offset in the code?

Thanks in advance!
J.



More information about the OSM2World mailing list