ContextCapture E.N.U. Projection

You mean you have only 3mx file?

Did some experiments and it seems Alias Wavefront OBJ doesn't have option to offset the local coordinates. They are fixed as is so some coordinate systems can't be used as too much numbers causes loss of precision.

That is why there are many different approaches how to write SRS and its origin coordinates(.fwt world, .prj., .lua) Metadata.xml is Contextcapture helper file for exporting SRS and offset for OBJ. What is silly is that Acute3D or Microstation doesn't use this helper file. Not sure if there is other helper format which Microstation understands but you can reference the OBJ relative and change scale so it aligns correctly.

So only option besides creating correct output from ContextCapture would be to try to reproject the OBJ using CloudCompare or Meshlab. Unfortunately from helper file it is clear that there is no known georeference for your dataset. as it should look different if it is georeferenced.

<?xml version="1.0" encoding="utf-8"?>
<ModelMetadata version="1">
	<!--Spatial Reference System-->
	<SRS>EPSG:4326</SRS>
	<!--Origin in Spatial Reference System-->
	<SRSOrigin>56.12345,26.12345,71.00</SRSOrigin>
</ModelMetadata>

I was trying to handle every use case of data that I could be given, and making sure I exhausted all my options for handling a dataset that had ENU coordinates. I'm not given prior information to the data that I'm ingesting, so if there isn't enough data in the OBJ/metadata.xml then I guess I really can't do much with it then. Thanks for the assistance.

I know this is an old thread, but I wanted to share my findings in the hope that others might find it useful.  I've been trying to find a way to create models from a subset of ContextCapture tiles, and I need to convert the ENU extents to geodetic, so I can clip the appropriate area from the ortho imagery (which is EPSG:4326, or WGS84) so they match.

After a little digging, I found an algorithm for converting ENU to a number of other coordinate systems.  You can find it here:

https://github.com/ethz-asl/geodetic_utils

Apparently, the ContextCapture definition of ENU matches this package's description, which can also be found here:

http://www.dirsig.org/docs/new/coordinates.html

There seems still are issues in CC with coordinate transformations from E.N.U as in some coordinate systems the model is wrong.

Thanks for the info Michael. I haven't looked into this problem in a long time, but if I remember correctly I do recall looking at this library and it didn't seem to work for my use case (could have done something wrong though if it works for you).

It depends if OBJ has large coordinates and it is not locally transformed. But if OBJ contains actual coordinates then it may not correctly display because of floating point rounding.

It depends if OBJ has large coordinates and it is not locally transformed. But if OBJ contains actual coordinates then it may not correctly display because of floating point rounding.