Import .las or .e57 not scaling correctly regardless of what template I select?

Elmtec-Adam · July 12, 2023, 6:41pm

If you want to use e57 but th source coordinates are in inches - then it IS scaled incorrectly.
Which you don’t want to do, which is fine - the data is going to be scaled somewhere, whether you do that in the viewer or with the source data is probably irrelevant to be honest - SketchUp works in Float64 for calculations I believe.

So that leaves you with only the LAS file , the user from the thread you made in March said they used Lasinfo to validate the file and they could see that the header affected SketchUp/SE just fine - they did offer to check yours for you.

The tool they used is here
https://lastools.osgeo.org/download/LAStools.zip

What is the source of the LAS file?
If you want to share it , wetransfer it and I’ll see if I can get to the bottom of it - I presume it is the correct scale when you open the LAS in ArchGiS Pro?

Or are you using ArcGis Pro to generate point clouds from other sources?

Once you’ve got the point cloud being interpreted correctly, you can use any display unit in SketchUp as you normally would and see ft and inch or meters - that’s entirely independent from this.

SailingSketcher · July 12, 2023, 7:06pm

I can’t share this data with anyone. The source is a Phoenix LiDAR system that another entity used to collect the data and yes it is correct when opened in ArcGIS Pro.

Elmtec-Adam · July 12, 2023, 7:21pm

Have a look at Lasinfo and see what it comes out with.

Browse to the file in lasinfo.exe (in the bin directory)
hit run64
start
the command prompt that is already open will display the headers.

The file I’m looking at shows similar readouts to the SketchUp team member from your thread in March.
The sample fie I’ve just looked at shows:

I’m having a look around - this is of course a minefield of metadata and a chain of software.
I think these are all of the valid units as per spec - I imagine it will have to see one of those to be seen correctly.

Linear_Meter = 9001
Linear_Foot = 9002
Linear_Foot_US_Survey = 9003
Linear_Foot_Modified_American = 9004
Linear_Foot_Clarke = 9005
Linear_Foot_Indian = 9006
Linear_Link = 9007
Linear_Link_Benoit = 9008
Linear_Link_Sears = 9009
Linear_Chain_Benoit = 9010
Linear_Chain_Sears = 9011
Linear_Yard_Sears = 9012
Linear_Yard_Indian = 9013
Linear_Fathom = 9014
Linear_Mile_International_Nautical = 9015

Anssi · July 12, 2023, 7:29pm

The three countries that don’t use meters (Liberia, Myanmar and another) cause endless confusion to all the rest.

MikeWayzovski · July 12, 2023, 7:33pm

off topic

There are also feet pointclouds:

SailingSketcher · July 12, 2023, 7:44pm

I love it, but, is that point cloud foot actually 1’ US ft long?

SailingSketcher · July 12, 2023, 7:45pm

Will do!

Anssi · July 12, 2023, 7:50pm

Define foot…
Afaik it is a derived unit, 12 inches, where the definition of an inch is an arbitrary 25.4 millimeters.

SailingSketcher · July 12, 2023, 8:10pm

Okay, I ran lasinfo on the file and I think I see some relevant information on this:

The 3rd line from the bottom: UNIT [“US survey foot”, 0.3048…AUTHORITY[“EPSG”,“9003”]

So am I correct in that the units are being correctly stated as well as a universal scaling factor that would be used upon import?

Elmtec-Adam · July 12, 2023, 8:46pm

Something is being stated - could it be those are in relation to the geographical location of the data for the las, rather than the XYZ coordinates of the point cloud.?

:edit
I can see that type of data divorced from point clouds such as here, which also reinforces that.
NAD27 / Texas North + NGVD29 height (ftUS) - EPSG:7407

COMPD_CS["NAD27 / Texas North + NGVD29 height (ftUS)",
    PROJCS["NAD27 / Texas North",
        GEOGCS["NAD27",
            DATUM["North_American_Datum_1927",
                SPHEROID["Clarke 1866",6378206.4,294.978698213898,
                    AUTHORITY["EPSG","7008"]],
                AUTHORITY["EPSG","6267"]],
            PRIMEM["Greenwich",0,
                AUTHORITY["EPSG","8901"]],
            UNIT["degree",0.0174532925199433,
                AUTHORITY["EPSG","9122"]],
            AUTHORITY["EPSG","4267"]],
        PROJECTION["Lambert_Conformal_Conic_2SP"],
        PARAMETER["latitude_of_origin",34],
        PARAMETER["central_meridian",-101.5],
        PARAMETER["standard_parallel_1",34.65],
        PARAMETER["standard_parallel_2",36.1833333333333],
        PARAMETER["false_easting",2000000],
        PARAMETER["false_northing",0],
        UNIT["US survey foot",0.304800609601219,
            AUTHORITY["EPSG","9003"]],
        AXIS["Easting",EAST],
        AXIS["Northing",NORTH],
        AUTHORITY["EPSG","32037"]],
    VERT_CS["NGVD29 height (ftUS)",
        VERT_DATUM["National Geodetic Vertical Datum 1929",2005,
            AUTHORITY["EPSG","5102"]],
        UNIT["US survey foot",0.304800609601219,
            AUTHORITY["EPSG","9003"]],
        AXIS["Gravity-related height",UP],
        AUTHORITY["EPSG","5702"]],
    AUTHORITY["EPSG","7407"]]

SailingSketcher · July 12, 2023, 9:52pm

So the data I was showing wasn’t related to the point cloud objects, but the georeferenced data…which is separate from the “structure” of the point cloud…right? So I should look more at my data?

Elmtec-Adam · July 12, 2023, 9:58pm

Yeah, I think you are looking some something closer to mine

SailingSketcher · July 12, 2023, 11:48pm

I think I found it…but now I don’t know what to do to correct it…

3DxJFD · July 12, 2023, 11:59pm

Getting the impression info on the coordinate reference system (CRS) for Pheonix Lidar can be found here: Configuring Coordinate Reference System - Phoenix LiDAR Systems User Manual

You’re NAD83(2011) by the looks of it. Vid ref here: Export Cloud - Phoenix LiDAR Systems User Manual

In the video (same ref type), the speaker states “most importantly… unit set to meters… but all unit should work”.

If there was an error/incorrect setting on export, it doesn’t seem straight forward to change an import setting to fix it.

Do you have access to the generation reports? Can you see if there are warnings for discarded NAD83 in the header info? Project Report - Phoenix LiDAR Systems User Manual

Are EPSG 7019 1116, 8901 and 9003 compatible?

Can you change the las format between 1.2 and 1.4? Some recent comments in the Trimble Community indicate that las 1.2 is working (in TBC) but 1.4 are causing issues with the header info.

Elmtec-Adam · July 13, 2023, 11:40am

I think you are getting closer - I still am not sure if that is the correct part, but to my eyes that does look like the part of the header where you would find it.
It may be that the parameters are simply not there at all - which would be the same as them being blank.

I’ve found a couple of other posts in other places, it seems like this is a fairly common issue when you move out of GIS-land into 3D land.

and autodesk developer here has mentioned they’ve come across software that doesn’t write the necessary headers for Recap also.
US Survey Foot & Point Export to Civil 3D - Autodesk Community

sWilliams · July 13, 2023, 4:03pm

Two comments - err - three comments

The lasinfo spatial reference information you posted above is just fine and correct.
When the LAS file is open in CloudCompare the spatial reference information is viewable in the properties of the dataset.

and thirdly when using CloudCompare, savings the file in e57 format will cause the spatial reference information to be lost. Here’s a sneak peak at the source code.

// Save a dummy string for coordinate system.
// Really should be a valid WKT string identifying the coordinate reference system (CRS).
root.set("coordinateMetadata", e57::StringNode(imf, ""));

sWilliams · July 13, 2023, 5:51pm

I see now that if you use CloudCompare to ‘tile’ the data, the spatial reference is dropped in the resulting LAS files.

So when I return to this subject I’ll either write an extension to accomplish this task (I have all of the pieces written as parts of other projects) or present a tutorial on how to do this with las2las.exe an open source tool from GitHub - LAStools/LAStools: efficient tools for LiDAR processing

Here’s the readme for las2las. the options is named keep_tile.
las2las_README.txt (24.5 KB)

kevin58 · July 13, 2023, 7:25pm

That’s really useful information. So under these circumstances the .e57 file is read by SE in accordance with the rules (.e57 is always in metres) hence 120’ becomes 120M.

Elmtec-Adam · July 13, 2023, 7:41pm

Is the Spatial reference the pertinent part here?

@Yannick_SU can you give any more insight?

sWilliams · July 13, 2023, 11:22pm

A LAS file may contain, in addition to the data points, a set of metadata called variable length records. Think of these as Post-It notes stuck into the file. On those Post-It notes the creator of the file can save any sort of data they wish. If a LAS file is GeoReferenced it will contain a specific set of notes, below is an example of such, which contain the spatial reference info. Spatial reference system - Wikipedia.

variable length header record 1 of 2:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34735
  length after header  40
  description          'by LAStools of rapidlasso GmbH'
    GeoKeyDirectoryTag version 1.1.0 number of keys 4
      key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
      key 3072 tiff_tag_location 0 count 1 value_offset 26917 - ProjectedCSTypeGeoKey: NAD83 / UTM 17N
      key 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_Meter
      key 4099 tiff_tag_location 0 count 1 value_offset 9001 - VerticalUnitsGeoKey: Linear_Meter
variable length header record 2 of 2:
  reserved             0
  user ID              'LASF_Projection'
  record ID            2112
  length after header  617
  description          'by LAStools of rapidlasso GmbH'
    WKT OGC COORDINATE SYSTEM:
    PROJCS["NAD83 / UTM zone 17N",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-81],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","26917"]]

Topic		Replies	Views
Scale isn't correct Scan Essentials scan-essentials	3	516	March 3, 2023
Point cloud file importing at wrong scale Scan Essentials advice , import	12	1067	June 21, 2023
Problems with export scaling Pro	9	3269	December 16, 2015
The Point Cloud I'm uploading is in Meters, how do I change the import unit to feet? Scan Essentials	4	989	March 9, 2023
Problems resizing and changing the scale LayOut	9	1763	June 20, 2017

Import .las or .e57 not scaling correctly regardless of what template I select?

Related topics