Point cloud from recap 5 attaching in wrong location

[JamesMaeding]

I've tried on Civil3D 2018 and 19 (latest updates on each), and get the same result.

My process is import a .las file to recap, and it correctly reads the system (CA83-VIF).

It processes no problem into .rcp, and coords are perfect in the recap viewer.

Then I open a new civil3d drawing, set system to CA83-VIF and units to us survey feet.

When I attach the point cloud, and check "use geographic location" it correctly sets the scale to 3.2808, as recap always assigns meters to units, even when it shows feet.

The problem is it gets the x y and z offset wrong, but the rotation is about right (0.3 degrees I think).

My point cloud comes in way far away. Happens in 2018 and 2019.

I then manually set the point cloud insertion point to 0,0,0 and that helped, but still far away.

Has ANYONE been able to pull in a point cloud from recap 5 into the right coordinates?

I think I've checked everything relevant, and tried a few things like setting insert units to unitless, unchecking scale inserted objects, and so on. I know how those things affect xrefs, so tried them on pt clouds.

Nothing has helped though. I can't post data publicly, but could PM it to someone if they wanted to try it.

thanks for any help!

[JamesMaeding]

I did run across some posts saying to set insunits to 1 (inches).

I played with that a bit, and found it actually works better to set to feet.

I realized I had insunits at 0, and switching it to inches or feet got the point cloud within 100 feet of correct.

That is not good enough though, and is still a fail. Within 6 feet would be acceptable, as I have noticed various imagery from nearmap and google earth is off by that much. I have a guru surveyor to consult on this, and he agrees the imagery is off. We have grid to ground scaling factors going on, but not anywhere near a 100 foot error should happen, maybe 2 feet on certain projects.

[Pointdump]

James,

100 feet screams International Feet/US Survey Feet problem. Multiply coords of a point in your cloud by 0.000002 (2 parts per million). Is that about how much it's shifted?

"...set system to CA83-VIF and units to us survey feet."

Not sure if it was fixed in 2018/19, but in 2016 you needed to set US Survey Feet units first, then the coordinate system. Check _UNITS to see if you do indeed have US Survey Feet.

Dave

[TerryDotson]

... process is import a .las file ...

Have you considered going straight to a TinSurface using this freeware?

Civil3D: Lidar Straight To TinSurface
There's a tool in there to project between known systems also.

[JamesMaeding]

@TerryDotson

I like the thinking, and have tries LASTools to process pt clouds to smaller sets of data I could TIN.

I think since point clouds are kind of new, everyone wants just SOME way to get a (< 1 million tris) TIN out of them.

All of the progs I have looked at could do that, like vision lidar for example.

The big gap in all those programs is we want an optimized TIN, not a grid sampled set of points which ignores the difference between flat and crumpled areas. I want big tris for flat areas, small ones for changing areas to capture the detail.

Carlson Precision 3D Topo is the closest I have seen to that, though it is not great at it, just ok.

I now use trimble business center for post processing to surface, as we have that as part of our stationary scanner equipment bundle.

Got side tracked there, but @Pointdump thanks for the idea. I will try a few more things, but my dwt is set to us survey feet, and I even have a .net routine on startup that sets that since its so important to our area.

I bet you are right, but c3d should not be sensitive to order of setting settings.

[TerryDotson]

... we want an optimized TIN, not a grid sampled set of points ...

To to make sure it's clear to anyone interested, the LIDARTIN tool in that freeware feeds every point inside the selected rectangle to Civil3D to create a TinSurface.  The only exception being the throwout of points that do not have a qualifying class, like trees, buildings, etc.  While it's not optimized, it's certainly not sampling.

[JamesMaeding]

@TerryDotson

How does that work then? Our minimum ground point cloud sizes are like 5 million, thinned down from 20 million if non-ground included. Civil3d will take forever making a tin with that many points, and who will want a surface that big?

The adesk workflows also seem to choke on real life size datasets, so I am wondering where people are getting these small datasets from.

We do both drone flights, and stationary scanners. Both give too many points to just pull into a surface that is light enough to actually use. Maybe you are assuming the user already thinned the data?

[TerryDotson]

It's about extracting only the portion that's needed to form an initial TinSurface that's manageable.  For example one user got hit with a situation where they needed a reasonably small area that happened to hit on the corners of four (4) different LAZ files that were on average 1.5GB each, that's 6gb of LAZ (ultra high compression).  They also wanted to bring in only ground points of course.

The main thing is that they had tried to use "R" and gave up after 3-4 days grind.  With our Mass Points Processor they brought in only the ground points they needed by specifying a limit polyline.  The resulting TinSurface wasn't screaming fast but it was usable, and contained ALL the points on the initial build.  I believe they used Civil3Ds Simplify Surface to speed it up after initial import.

In other words we don't thin, we simply don't bring in anything un-necessary.

[JamesMaeding]

@TerryDotson

I see, and that is indeed useful.

What would happen with us is we would still get too many points on about every job.

Not picking on the tools, they all have certain problems they solve.

I wanted to point out that optimizations step as whoever solves it for say $1000 a seat, will have a huge market share.

I paid $1800 for our network seat of Carlson P3D, and it is a good tool, so may be an opportunity for someone.

I was looking at the C++ library "PCL", but I am a .net guy and have not had time to review and try the wrappers out there.

or fun, install the carlson p3d trial and look at the program files. You will see all kinds of open source libraries used, including the PCL one. I wish I could work with their programmer, so many cool things that library can do.

I did see something that the expensive Carlson point cloud tool did, that I think is what I want. Its $5k though and I wanted to wait a bit before spending that.

[copper.chadwick]

@JamesMaeding,

Thanks for your contributing to the fourms! I see that you are experiencing some location anomalies when importing your point cloud from Recap in to Civil 3D. I have an Autodesk Knowledge Network article that relates to that. 

---

Recap File will not import into civil 3D properly

Issue:

When the recap file is inserted into the Civil 3D file the file shows the correct scale factor but never seems to come in at the right location in the state coordinate plane. The client tried inserting the RCP file into the drawing and the file comes in at the right size, but the wrong location. When i import the .LAS files directly they show up in the exact correct location and scale, but I cannot modify the point cloud.

Solution:

• Set insertion units (DDUNITS) to feet and re-attach.
• Set INSUNITS to 2

---

 I hope this helps as another direction to a solution. If so, please hit the Accept as Solution button if a post fully solves the issue or answers the question.​ Thank you for your participation, your accepting a solution adds value to the post for the community as a whole, and helps other members find answers to their issues.

[JamesMaeding]

@copper.chadwick

Well, thanks for the help!

Um, please read threads before replying with uber simple suggestions next time.

I'm guessing you are a sharp guy, but you need basic info to do support, that is just life.

thx

[autoMick]

@TerryDotson I just wanted to give a big shout out to you guys for supplying these LIDAR tools. Big kudos for stepping in at a time that Autodesk decided to drop the ball.

Cheers

Mick

[dfischer]

I had the exact same issue. It was obvious to me that it was in the projections that I was selecting as I was working in Recap and C3D. That is the only item that could cause the data to come into the wrong location.

In Recap you need to select the "Advanced" tab at the top after selecting your files to import. You need to select the correct "coordinate systems". For the LiDAR data that I was using, it is in UTM83-14 meters. My C3D drawing was set at State Plane Coordinates in US Feet. So for the target you need to find what ever coordinate system your C3D drawing is in and make it the same in the Target coordinate system.

Now you can import the files, index the scans and launch your project. Once your point cloud shows up in Recap you need to select the "Home" icon and select the "Settings" gear. Under the "General" tab it will give you the "Coordinate System". If you notice, this is the same as your target coordinate system you set above. Here is the magic box..... If you go down below, you will notice the units are in meters, even though the coordinate systems match. Change the meters to feet and then notice which feet units you are in. I had to change mine to feet and then select the US Feet for my particular coordinate system that I use. Now at least your Recap file will come into C3D in the right location.

[JamesMaeding]

@dfischer 

Good explanation, I had not noticed the meters unit setting you recommend changing.

I went and looked at my projects that were behaving, and noticed I leave that on meters:

recap.jpg

So in addition to your workflow, this process also works for me:

1) leave the units on meters in recap

2) in autocad, run UNITS command and set the insertion scale value to US Survey Feet:

units.jpg

3) run the POINTCLOUDATTACH command, and in the dialog, do not check the "use geographic location" box.

Mine is grey as I am in autocad, and part of the reason I am explaining all this is so you can use basic autocad with point clouds and get correct coords:

im.jpg

That is it, your cloud should come in dead on.

Step 2 is critical. I must have tried 20 things before realizing its importance.

[BrianHailey]

I had this same problem a while back. Even though my Civil 3D units where set to U.S. Survey Feet, the drawing units were still set to Feet. Changing the drawing units to U.S. Survey Feet did the trick for me.

[mmarenco]

any updates to this issue? I'm in the same exact boat. Using TBC to create the RCP from an LAS and once imported into Civil 3D the point cloud is off by 35 feet more or less. Drawing settings are all correct (units to feet, imperial to US foot, coordinate system correct) my units are also set to US Foot. I load GeoMap to check coordinates (I understand it can be a little off) but nothing I try helps my situation.

[Pointdump]

Hi @mmarenco,
"Using TBC to create the RCP from an LAS..."
Trimble Business Center? I thought only ReCap could create an RCP file that Civil 3D would accept.
"Drawing settings are all correct..."
Maybe, but I wouldn't bet the farm. @DisturbedCorner lists all the ways things can go sideways >>>Here<<<.
In which direction is your cloud off?
Dave

[JamesMaeding]

@mmarenco 

No, you are talking about a TBC to acad workflow, I was talking about Recap to acad.

While many of the same things apply, I have had good luck with TBC.

Yes, TBC does make .rcp files, but you need recap installed (the free version...).

I have practically forgotten recap now, its pointless (pun) as TBC is 10x faster at making the .rcp, as I think its indexing is being used somehow, and that is already done.

But I always have to set acad units to us survey feet, either workflow..