Point Cloud Scaling

[ericjhberg]

I have been trying to import a large point cloud and I cannot seem to figure out how to get it to the right scale.

 

I have tried every combination of units, both pre-setting drawing units and changing the point cloud import units and nothing I do has yielded successful results. The import has yet to come in at the right scale or x,y,z location.

 

Anybody out there with some tips?

Edited December 7, 2018 by ericjhberg

[ericjhberg]

@zoalord12 I have uploaded a test file to the following sharable link since .las files are not permitted on the forum.

 

https://app.box.com/s/z08lzjey9idopxrizmm1aqzde827m8dl

 

To be clear, this isn't a file specific instance, this is EVERY .las file I have ever tried to work with! When using a program like VRMesh to view the point cloud, it scales perfectly, but VW doesn't come close to matching that, regardless of the combination of document units and import units I try.

 

Any help is greatly appreciated.

[ericjhberg]

@Fahad Zafar This method flies in the face of traditional drafting practices...NEVER scale survey information! Lidar is survey information and we shouldn't have to scale it to make it work!

 

Again, when used in a point cloud software like VRMesh, there is no need to scale. This means that VW interprets the data differently than other software...inaccurately it appears. This is a big deal for those of us trying to utilize Lidar data as survey.

Edited December 7, 2018 by ericjhberg

[ericjhberg]

@Fahad Zafar I didn't realize that Lidar data is assumed to be Millimeters? In the example I provided, the units you returned are actually the correct values, but in Decimal Feet, not meters (or millimeters). The bounding box in real life units is 

X = 718.55 feet

Y = 380.82 feet

Z = 195.46 feet

 

If this is true of the units, how do I go about importing it into vectorworks in Feet without scaling the point cloud? Isn't this the intent of the Units selection on a Import Point Cloud Options dialog? The prompt states "Units of the points to be imported." Therefore it stands to reason that the Lidar is somehow unitless and that the Import Dialog sets the units? 

 

It's either that or that the Point Cloud is dimensioned; therefore it shouldn't matter what the document units are or the Import Settings? It should come in 1:1 regardless of unit.

 

FYI...I have figured out how to get relatively close by scaling the Point Cloud by 0.3048 (decimal conversion of meter to feet), but I'm not very fond of this solution because, as I mentioned before, scaling is generally a no go for survey information...particularly because the conversion between meters and feet is a running decimal; therefore, scaling will automatically introduce a level of conversion inaccuracy (granted 4 decimal places is a very low tolerance).

[RussU]

I work a lot with point clouds, and it's absolutely imperative to set VW to match the incoming unit prior to importing, so as to get predictable and accurate results.

Scaling after import will always introduce a level of rounding errors.

 

VW can cope with everything from millimetres to parsecs, which is a huge varience.

This is common behaviour across different platforms, and not a short-coming of VW alone. 1 divided by 25.4, resolves to far too many decimal places to be used with the super-accuracy that Lidar data posesses, so get the units right before import....

No harm in abandoning and re-trying if first import goes wrong. Much better than scaling after the fact.

 

[ericjhberg]

2 hours ago, Fahad Zafar said:

Then reset the origin to bottom left of your data in the "Top/Plan" view to see that your "feet" dimensions are correct and as expected.

 

Here is another problem that exists with scaling data...how can I be assured that the resulting origin after scaling matches the real-world survey x and y coordinates that are embedded in the data. Perhaps more important that the vertical reference, the horizontal reference of this data is imperative.

 

I hope that we can expect a fix of these inconsistencies soon.

[RussU]

A good point to note is where in space the file will be imported into. The origin is an important factor.

When you're using Geo-referenced data, you'll often find you're way off from the origin, unless you're off the south coast of Ghana.

While VW can cope with data a long way off, you start introducing floating point and rounding errors. This has always been the case.... Get your data as close to 0,0,0 as possible.

 

 

So I tend to export my points as a local co-ordinate system. This helps VW out.

If I need the location data of the site, I draw a grid underneath with the GPS grid manually entered. Not great, but it does work.

 

 

[ericjhberg]

On 12/10/2018 at 8:24 AM, Fahad Zafar said:

All the data is being multiplied by a factor of "1000" unnecessarily.

 

@Fahad Zafar This is not correct. The data isn't off by a factor of 1000, it is off by a factor of 3.28084 which is the decimal conversion from meter to feet.

 

Data that is imported as mm is being read by the software as feet, regardless of the unit the document starts in.

 

On 12/10/2018 at 8:24 AM, Fahad Zafar said:

thus this bug has actually passed through some recent changes.

Any reports on this issue getting fixed?

[tekbench]

If I had to guess, based on the phone call I just had with support (today, and last Friday), the answer is a resounding 'No update to report'.

I'm on 2019, SP1. Support said they could have an update on the issue for me today. No idea what that actually means.

See the thread:

".LAZ file coming in to document way out of scale."

I've pulled in a .LAZ and .LAS file, and they're not at scale, regardless of what units I select on import. I've clearly laid out what the issue is and I've provided more graphics that clearly tell the story from my side.

I've provided the files for Support, and they see the same thing when they import the files. They come in, and are way out of scale.

You CAN go through a bunch of gyrations and try and get your point cloud close to accurate, but unlike Plasio or a number of other software packages, Vectorworks just doesn't translate the incoming file properly. I think the import functionality of the tool needs to be thought out a bit more. It should literally be a 1:1 import, or a 'maintain units on import' or whatever. I'm seeing, essentially, bad math happening on import, based on what units I select in the 'import' dialog. Period.

Kelly.

 

 

[tekbench]

This needs to be moved to the Known Issues page. It is a known issue that Point Cloud objects do NOT come into Vectorworks drawings at the right scale. This thread and two other techs on the phone have confirmed it. Can I bump this to somehow show up on the known issues list?

[Jeff Prince]

Was this ever resolved?  @ericjhberg I just imported a point cloud into VW2020.  The cloud behaves in other software packages and can be measured.  When it arrives into VW, it is at 6.56168 larger than it should (2x the meter to feet conversion).  This is crazy if it's still broke.  I kind of gave up on VW in regards to point clouds a few years ago when I ran into issues that tech support could not solve.  I ended up working in Autodesk packages instead for that job 😞

[tekbench]

I'm trying it right now. I'll let you know how it goes.

[tekbench]

Can confirm. Not resolved, still a show stopper.

This fails in the same way using VW202 as it does in VW2019.

I just repro'ed this on two laptops side by side. One running VW2019 SP4, the other running VW2020 SP3.1

Seriously bummed here.

Kelly.

[ericjhberg]

@tekbench Thanks for confirming...I kinda gave up too. I'm not surprised that VW hasn't figured this one out. My experience is that they rush tools to the market just to say that they can manage Point Clouds and then wait years to provide them the full functionality needed to make them practical and useful to users. This is just one of many examples of this.