Is there a reason a translation results in double the expected coordinates?

[joseph.he]

ElementTransformUtils.MoveElement(document, elementId, coordinates.Divide(2));
ElementTransformUtils.MoveElement(document, elementId, coordinates);

Coordinates is an XYZ object that specifies the desired coordinate of my imported object. The import is initially at the origin so coordinate is passed as translation. However, without the Divide by 2, the coordinate is not at the desired location. For example if I set the desired as (1,1,1). The translation will result in (2,2,2) Why is that? The element goes to the desired location if the imported file is family, but will have to divide by 2 if it is DWG or OBJ file.

[jeremy_tammik]

Your code is erroneous. The first line lacks a closing bracket, the second line has one too many.

[RPTHOMAS108]

I don't from what you described see an obvious reason why that would occur but in such instances of doubt a more descriptive version of the full process you are following may point to an obvious reason.

Inserting the dwg with what options?

Establishing it is initially at origin by what method?

Assessing the offset by which means?

It is sensible (to me) that if you offset by 1 ft in each direction the dwg should move 1 ft in each of those directions from where it was (regardless of where it was or what scale it was). So I'm asking if you are measuring the same geometry within the DWG before and after or are you making some assumption about the origins of the dwg and Revit document?

[joseph.he]

Thank you for pointing that out. I made an error when making the post but the code in the addin is not erroneous. I have the updated the post to prevent confusion.

[joseph.he]

"Inserting the dwg with what options? Establishing it is initially at origin by what method?" (Below is my code)

DWGImportOptions importOptions = new DWGImportOptions();
importOptions.Placement = ImportPlacement.Origin;
importOptions.ReferencePoint = new XYZ(0, 0, 0);
// Not sure if this is necessary but keep it for now
importOptions.AutoCorrectAlmostVHLines = true;

"Assessing the offset by which means?" (Below is my code)

XYZ coordinates = ConvertToTranslationXYZ(objects[i].coordinates, position);
// Move to the desired location 
//ElementTransformUtils.MoveElement(document, elementId, coordinates.Divide(2));
ElementTransformUtils.MoveElement(document, elementId, new XYZ(coordinates.X, coordinates.Y, coordinates.Z));

The offset from the origin is calculated based on the real world northing and easting, by comparing it to the survey points northing and easting, then converting the translation to feet and Revit coordinates. Assuming the translation is not a problem would there be a reason why the problem occurs?

I am checking the coordinates after import and translation by the following code

ImportInstance instance = element as ImportInstance;
position = instance.GetTransform().OfPoint(instance.GetTransform().Origin);

"So I'm asking if you are measuring the same geometry within the DWG before and after or are you making some assumption about the origins of the dwg and Revit document?"
Sorry, I am quite new to Revit API and although I have tried my best to read the documentation and the building coder blogs, there are still many gaps in my understanding. If I am just translating the geometry in the revit model is the measuring of the DWG geometry necessary? I dont quite understand that question. 

Thank you for the reply and any help is really appreciated!

[RPTHOMAS108]

To simplify things and take base points out of the equation:

Say the dwg contained a rectangle if you measure the distance between the same point of that dwg before and after the movement vector of (1,1,1) is the resulting 3D distance 1.732 ft i.e. 1ft in each direction? This is what I would expect if you move it with a vector of 1,1,1.

If that is the case then perhaps the issue is with ConvertToTranslationXYZ?

What you have to consider with the base points in Revit is that they have parametric offsets i.e. they have a physical location in Revit internal co-ords and then at that location they have a parameter noting what that physical location represents at that point in terms of rotation and offset. There are methods that will convert from shared co-ords to Revit model co-ords without having to really consider such things i.e. there is an easy way and a hard way.

Mostly you should be working with the internal system if you need to convert from shared coords to internal system then you should create a transform for that purpose (similar to below but inverted).

https://thebuildingcoder.typepad.com/blog/2012/06/real-world-concrete-corner-coordinates.html#4

This above uses old API transform methods I note but there are equivalents

I've used this in the past to convert from shared to internal. It is basically an updated version of the above but inverted (since I was converting from shared to internal).

    Public Shared Function GetModelLocationTransformed(doc As Document, PNT As XYZ) As XYZ
        ' Retrieve the active project location position.
        Dim projectPosition As ProjectPosition = doc.ActiveProjectLocation.GetProjectPosition(XYZ.Zero)
        ' Create a translation vector for the offsets
        Dim translationVector As New XYZ(projectPosition.EastWest, projectPosition.NorthSouth, projectPosition.Elevation)
        Dim translationTransform As Transform = Transform.CreateTranslation(translationVector)
        ' Create a rotation for the angle about true north
        'Dim rotationTransform As Transform = Transform.Rotation(XYZ.Zero, XYZ.BasisZ, projectPosition.Angle)
        Dim rotationTransform As Transform = Transform.CreateRotation(XYZ.BasisZ, projectPosition.Angle)
        ' Combine the transforms 
        Dim finalTransform As Transform = translationTransform.Multiply(rotationTransform)
        'Return finalTransform
        Return finalTransform.Inverse.OfPoint(PNT)
    End Function

If I were using this now I think I would probably keep hold of the created transform elsewhere rather than creating it for every point conversion i.e. only extracting the parameter values from Revit once etc. (as in original example).

[joseph.he]

Thank you for the code snippet! I have been experimenting with the provided code and took a closer look at transforms.

Seems like the following code is not giving me the distance from the origin, at least not the origin I was thinking of.

checkPosition = selected.GetTransform().OfPoint(selected.GetTransform().Origin);

 Once the following util is called

ElementTransformUtils.MoveElement(document, elementId, coordinates);

 The transform origin is also translated to the specified coordinates. So If I understood it correctly, checkPosition is applying transform to an already translated origin resulting in twice the expected coordinates.

[RPTHOMAS108 · Accepted solution]

I don't understand why you are feeding a transform origin into .OfPoint?

If the transform has an origin of 0.0,1 and you use .OfPoint then yes it will add 0,0,1 to 0,0,1 resulting in 0,0,2

The transform of the object represents it's location within the global system, so if you apply the inverse it will move back to origin if you apply the non inverted transform it will move further away.

It seems whatever the secret of your function 'ConvertToTranslationXYZ' holds that is the key to understanding what you are doing wrong. Ultimately you move an item with a vector of 0,0,1 with the ElementTransformUtils and it moves 0,0,1.

[joseph.he]

I can't seem to find the forum post I was looking for, but I misunderstood the following code that I have read as an answer to "how to find the coordinate of an imported instance"
selected.GetTransform().OfPoint(selected.GetTransform().Origin);
I wanted a way to find the coordinates of an imported element as the Location property seems to be null for imported instances and I thought the above code would give me the coordinates.

In terms of the translating the model. I have realized the model gets translated to the correct spot after further testing, I was just confused why it kept logging coordinates that were double its expected coordinates. And I have figured out "If the transform has an origin of 0.0,1 and you use .OfPoint then yes it will add 0,0,1 to 0,0,1 resulting in 0,0,2" is precisely why its logging double the coordinates.