Match IW360 objects XY rotation to surface answer day

[blueping]

I would like to "mapexport" objects from Civil 3D to IW360, so that XYZ rotation information is getting mapped into IW360.

I managed to do that for the Z rotation. However, there is always an offset error of ~0.9 degrees.

What I did is "mapexport" in C3D, then in the data tab>source field I choose rotation. Then export as .shp.

In IW360 it will come in radians, so in the rotation Z is use the formula: "rotation*180/3.1415". The offset error is always been ~0.9 degrees for me. so I modify that into "(rotation*180/3.1415)+0.9)". This is working for me, but is that offset a bug or I did something wrong?

As for the XY rotation I've tried something fancy but failed.

If you're interested what I've tried:

I select my surface, then use add a slope label on the point I would like to match the XY values. Then I explode the slope text now has a rotation. I mapexport the "contents" of the text and the "angle" of the text. Going into IW360 I can extract the Euler angles (XY rotation) from it by doing a transformation:

Sin ( Atan ( (1/ToFloat ( Contents  ))*180/3.1415 ) )*Cos ( Rotation *180/3.14  )
Sin ( Atan ( (1/ToFloat ( Contents  ))*180/3.1415 ) )*Sin(Rotation *180/3.14)
Rotation *180/3.14

However, here is where I failed.

1. tan is a assymtotic function. for those values I would get an error. for all non-exploding value it's alright.

2. the angle of the text doesn't contain information of which of the 2 directions the "slope label"-arrow is pointing at

[Wind.Wu]

May I know the coodindate system setting for 

1. Civil 3d drawing and exported .shp file
2. InfraWorks Model, including the  Database and UCS ?

TIPs: You can get the InfraWorks CS setting in the Model Property dialog.

[blueping]

I've set C3D coordinate system to :"Netherlands-RD", UCS to world

IW360 database: LL84

tried both UCS Netherlands-RD and UCS LL84.

edit additional info: my objects come in at the right location, just the Z-rotation has a offset of 0.9 degrees

edit 2: the shp file defaults selects Netherlands-RD for me

[haik2]

how do you import the shp file into IW? Can you add screen shots of the various data source config tabs in IW? Maybe even attach the shp file?

Then I could try to reproduce your effect.

Thanks a lot,

Haik.

[John_DeLeeuw]

@blueping, you are probably using gradians instead of decimal degrees within your C3D template. That explains your 0.9 degree mismatch because one gradian is 9/10th of a decimal degree.

Can you check that and let me know if this is the case?

[blueping]

@John_DeLeeuw my drawing is set on degrees, however the mapexport will still export the value into IW360 as radians. The 0.9 offset is an absolute value. every single mapexport I have to +0.9

[blueping]

@haik2

it took me some time to create the screens and .shp files, but here they are

[blueping]

The system didn't allow me to post more than 3 attachments

[John_DeLeeuw]

@blueping, you are correct that Mapexport defaults to radians for rotation values in its export. So this is not InfraWorks related but rather Map/Civil 3D.

I do have a possible workaround for you, follow these steps:

1. Create an Object Data table in Civil 3D with a Rotate parameter (Real)
2. Attach the Object data table to your chosen objects, can be anything
3. Save your DWG drawing
4. Open a new drawing and Map Attach your source drawing containing the rotated objects
5. Perform a DWG Query and use the Alter Properties option to transfer the original Rotate Z value to your created Rotate Parameter
6. Do another Mapexport and make sure you use the new Rotate parameter, which has now become a numeric value
7. Import in InfraWorks and match the Rotate attribute

Let me know if this works out for you?

[blueping]

@John_DeLeeuw

thank you for your suggestion.

However that workaround doesn't work for me. Even if I don't use mapexport. when I just manually measure the angle in degrees in C3D, then manually type in that value into IW360. There is still an offset of -0.9 degrees.

So in the formula I just +0.9 degrees. See the pictures I attached above.

That workaround works for me, I was just wondering if that's a bug or I did some wrong thinking.

My true question is to match the XY-rotation too: for example I want the 4 wheels of my car to (almost) touch the ground.

[haik2]

Thanks for the files! The problem is this: You set your positions and rotation angles in Civil in the Netherlands-RD system. When you import it into IW, positions get converted to the geocentric coordinate system (internally, IW puts everything into the geocentric CS). Rotation, however, is just a db column, so IW can't apply any transformation to that value. The 0.9 degrees misalignment you observe is exactly the false northing of Netherlands-RD at your target location.

Unfortunately, I can't give you any neat fix for this situation. Probably it would be helpful if IW would provide a function to compute that angular deviation so that you could use it in an import script.

Haik.

[blueping]

@haik2

Thank you for your explanation, although I don't fully understand it now, maybe someday I will.

I will continue to use the +0.9 workaround.

But my more important problem is: how do I match objects like a car to the surface so 4 wheels are touching the ground without manually trial & error with the XY-rotation values?

[haik2]

Maybe one workaround is to convert the rotation to LL84 in Civil. That should align it to IW's geocentric CS. But I don't know how to do that. Maybe John has an answer to that.

[scunningham]

Objects, like City Furniture, don't necessarily sit on the terrain properly without some editing. You may have some success using Road Decorations to model a single car sitting properly on a roadway; this may not be workable depending on where you're trying to place the cars.

For those unfamiliar with the workaround used to adjust how City Furniture sits on the terrain, this article explains it:

https://forums.autodesk.com/t5/infraworks-360-infratips/editing-vehicles-and-any-other-city-furnitur...

[Wind.Wu]

The "best practices" depends on the format of source data. Could you please share a simple sample of your source data to us? 

[blueping]

@scunningham

thank you again for your reply.

The method you suggested is exactly what I not want to do, manually editing XY of every object. Hench I've been trying something fancy described above and hitting a dead end.

@Wind.Wu

I'm not sure what you mean by "source data". I'm trying to match XY rotation of a IW car with a surface I created in C3D. The workflow I've tried discribed above failed.

[Wind.Wu]

If I understand right. the workflow you are doing now is

1. the car in C3D is just a Point with x,y,z (rotation)
2. export the point feature to .shp through mapexport command
3. import the .shp file in InfraWorks
4. Expect the cars are positioned to the right location with right rotation.

Are there any other properties associated to the car feature?

Kindly correct me if I am wrong about the worklow

[blueping]

@Wind.Wu

Thats about my workflow, exept for step 4.

This workflow I came up with only works about 49.99% of the time reasonable; 49.99 % of the time almost (only have to correct the minus signs). the rest is incorrect 😄

Let me clarify step 1:

I select my C3D surface, then I add a single point slope label and put it on a spot I would like to place my car at.

The result is having 3 pieces of information: 1. geolocation of the point in XY; 2. The slope of that particular point; 3. direction of that slope

with info 2 and 3 I can calculate the IW360 XYZ rotation of the object. (convert to Euler angles)

The slope label I change one that it displays decimal slope (see attachment), then I explode twice. Resulting a mtext with attribute "contents" as the slope info. now I mapexport the mtext as a point, with datasource fields "contents" and "mtext rotation"

now lets look at my script formulas:

X rotation: Sin ( Atan ( (1/ToFloat ( Contents  ))*180/3.1415 ) )*Cos ( Rotation *180/3.1415  )
Y rotation: Sin ( Atan ( (1/ToFloat ( Contents  ))*180/3.1415 ) )*Sin(Rotation *180/3.1415)

lets work form inside to ouside. first I convert "contents" into a number with "Tofloat". the [*180/3.1415] is to adres the radian/degrees problem. the 1/x is because I need rise over run ( or the other way around)

Now we do some of the twice trigonometric functions (high school math :D) to convert the 2 pieces of info into Euler angles.

now, why doesn't my workflow only works for about 49.99%?

1: atan is a function with asymptote. it happens when you're parralel with the axes. I need a if-then-else function in the scripting to detect the asymptotes. but the IW360 "table" tab fields doesn't have this if-then-else. I think I could do this in the IW360 "script" tab > edit, but then I would forfeit the auto script generation.

2: I didn't include the info which way the arrow in the attachement picture is pointing at. I lost information before I mapexported. So I need to correct this in IW by adding a minus sign at the the X or Y rotation property.

also I still need to adjust the Z-rotation in IW360

conclusion: my little experiment can't be called a real success. I'm not sure if you can learn anything about this faillure 😄

And I know it's kinda not very clear how I explained this all, but I've tried my best.

short summary, I've tried to convert "C3D slope+direction" into "IW360 XY rotation" and failed 70%

[elliott.rosenfeld]

Thanks for providing your workflow in such detail, this is really helpful for when we try to replicate and find a solution for you. I have contacted several Autodesk employees who have experimented with similar workflows before, and they will be responding as soon as possible, although this may not be before the end of day.

Thanks,
Elliott

[haik2]

Regarding the false northing: I mixed up terms here. False northing refers to avoiding negative y coordinates by adding some defined offset. The 0.9 degrees are the deviation between the north direction in the Netherlands-RD CS and the north direction in IW's geocentric CS. Such a deviation is always present in any projected CS (since the geoid is projected to a plane). It depends on the location.

For solving the atan issue, there is another function atan2(x, y), which takes care of the quadrants and singularities. The x and y parameters are the direction (no need to normalize the vector) and the result is an angle (see http://en.cppreference.com/w/c/numeric/math/atan2 for a deeper explanation). Maybe that way you can handle the signs automatically.