Jump to content
  • 2

Point Cloud Scaling


ericjhberg

Question

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 by ericjhberg
  • Like 1
Link to comment

19 answers to this question

Recommended Posts

  • 0

@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.

  • Like 1
Link to comment
  • 0

@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 by ericjhberg
  • Like 3
Link to comment
  • 0
  • Vectorworks, Inc Employee

LIDAR data is generally assumed to be in milli-meters. Can you tell me the difference in scale between the VRMesh import and the Vectorworks import ?

 

I see that VRMesh has different bounding box measurements compared to Vectorworks (see image).

I checked with a 3rd software CloudCompare, and the numbers match exactly with whats in Vectorworks (see image). I changed the origin and set the Units of the Vectorworks page to meters.

 

So now we have a 3rd software matching the import numbers of Vectorworks, and we have VRMesh.

 

If you look closely, they are all the same in all 3 softwares.

 

the bounding box is:

X = 718.55

Y = 380.82

Z = 195.46

 

if you subtract the limits of the VRMesh Bounding Box, you will get the same numbers.

 

 

comparing_vw_with_cc.png

vr_mesh.png

  • Like 1
Link to comment
  • 0

@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? 

image.thumb.png.980e65854bb456bde130623a2235977a.png

 

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).

  • Like 2
Link to comment
  • 0
  • Vectorworks, Inc Employee

Hi Eric,


Your understanding of the "Units" pop up is correct, if you select it, you should get the data imported in those units. That is not happening for “feet”. I noticed that all the test data we have is actually in “mm” thus this bug has actually passed through some recent changes. Thank you for reporting it.

 

This is the problem:

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

 

This is the workaround (for now, this will be fixed in an upcoming Service Pack):

When importing your data, select "feet" as the units. Once the import is done, scale by a factor of 0.001.

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.

 

 

Regards,

Fahad

 

 

 

  • Like 1
  • Dislike 1
Link to comment
  • 0

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.

 

  • Like 3
Link to comment
  • 0
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.

  • Like 1
Link to comment
  • 0
  • Vectorworks, Inc Employee

Resetting the origin to the bottom left is just a test to confirm to you that the data coming in has the correct bounding box, since the scan points are not 0-based.

If you want to keep the original, then don't change the origin.The origin is just a point of reference.

 

When you scale something and undo the scaling, the origin is preserved. Not only that, the actual values are also exactly the same as the original.

 

Did you know there is a scale factor X Y Z that is part of the LIDAR data header ? 

Reading the data from your file can trigger scaling based on your LIDAR file (see image) per point value.

 

 

 

format header.png

  • Like 2
Link to comment
  • 0

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.

 

image.thumb.png.52b291a494e329d7b5a8009295ba276c.png

 

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.

 

 

image.png

  • Like 1
Link to comment
  • 0
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?

  • Like 1
Link to comment
  • 0

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.

 

 

  • Like 1
Link to comment
  • 0

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?

  • Like 1
Link to comment
  • 0

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 😞

Link to comment
  • 0

@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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...