2

Disclaimer: This is a duplicate of this, a question without an answer. This is not, however, a duplicate of this, as it is a different error.

I have a LAS file projected in EPSG:32636, and I need to reproject it to EPSG:4326.

When I try to reproject it, using code found here to convert it to a format CesiumJS can show, it runs:

las2las --a_srs EPSG:32636 --t_srs EPSG:4326 ../cloud.las --scale 0.000001 0.00 0001 0.01 -o tmp/p.las

Which returns the following error:

error: X scale and offset combination is insufficient to represent the data

I played around with the scaling values, and values that work are between 0.01 and 1, but not for example 0.001, and I don't understand why. When visualizing the new las file, it is a points cloud in the right location, but all of the points condense to a single pixel.

The file's header states as follows:

 Header Summary
---------------------------------------------------------

  Version:                     1.2
  Source ID:                   0
  Reserved:                    0
  Project ID/GUID:             '00000000-0000-0000-0000-000000000000'
  System ID:                   'libLAS'
  Generating Software:         'libLAS 1.8.1'
  File Creation Day/Year:      135/2018
  Header Byte Size             227
  Data Offset:                 1081
  Header Padding:              0
  Number Var. Length Records:  3
  Point Data Format:           3
  Number of Point Records:     1541011
  Compressed:                  False
  Number of Points by Return:  0 0 0 0 0
  Scale Factor X Y Z:          0.00100000000000 0.00100000000000 0.00100000000000
  Offset X Y Z:                681000.000 3552000.000 0.000
  Min X Y Z:                   681113.173 3552810.731 41.752
  Max X Y Z:                   681389.296 3553078.302 69.555
  Spatial Reference:
PROJCS["WGS 84 / UTM zone 36N",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",33],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","32636"]]

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GTCitationGeoKey (Ascii,22): "WGS 84 / UTM zone 36N"
      GeogCitationGeoKey (Ascii,7): "WGS 84"
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      ProjectedCSTypeGeoKey (Short,1): PCS_WGS84_UTM_zone_36N
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter
      End_Of_Keys.
   End_Of_Geotiff.


---------------------------------------------------------
  VLR Summary
---------------------------------------------------------
    User: 'LASF_Projection' - Description: 'GeoTIFF GeoKeyDirectoryTag'
    ID: 34735 Length: 64 Total Size: 118
    User: 'LASF_Projection' - Description: 'GeoTIFF GeoAsciiParamsTag'
    ID: 34737 Length: 30 Total Size: 84
    User: 'liblas' - Description: 'OGR variant of OpenGIS WKT SRS'
    ID: 2112 Length: 598 Total Size: 652
---------------------------------------------------------
  Schema Summary
---------------------------------------------------------
  Point Format ID:             3
  Number of dimensions:        16
  Custom schema?:              false
  Size in bytes:               34

  Dimensions
---------------------------------------------------------
  'X'                            --  size: 32 offset: 0
  'Y'                            --  size: 32 offset: 4
  'Z'                            --  size: 32 offset: 8
  'Intensity'                    --  size: 16 offset: 12
  'Return Number'                --  size: 3 offset: 14
  'Number of Returns'            --  size: 3 offset: 14
  'Scan Direction'               --  size: 1 offset: 14
  'Flightline Edge'              --  size: 1 offset: 14
  'Classification'               --  size: 8 offset: 15
  'Scan Angle Rank'              --  size: 8 offset: 16
  'User Data'                    --  size: 8 offset: 17
  'Point Source ID'              --  size: 16 offset: 18
  'Time'                         --  size: 64 offset: 20
  'Red'                          --  size: 16 offset: 28
  'Green'                        --  size: 16 offset: 30
  'Blue'                         --  size: 16 offset: 32
  • As you indicated, this is a duplicate question of the following: gis.stackexchange.com/q/63915/8104. The preferred approach would be to add a bounty to the old question rather than opening a duplicate question. – Aaron Aug 16 '18 at 4:57
  • Fair enough, didn't know I can do that. Will do in the future – Amit Aug 16 '18 at 6:43
  • There is a typo in your code, the second scale parameter has a blank between two zeros 0.00 0001. Have you checked that? – Andre Silva Sep 13 '18 at 16:23
0

Scale refers to the precision of the coordinates, and is used in combination with the XYZ point within the points record and the offset to position the point in the coordinate system specified. A common way for coordinates in LAS files to be represented is as long integers, with a precision of 3 digits and a scale of 0.001. Therefore, if an X point was 540000000, the offset was 0, and the scale was 0.001, the point would be positioned in a viewer at X point 540000. If the offset was 12 (offsets are added without scaling), the point would be positioned at X point 540012. Your original file has this scale factor. You'll also notice that their minimum X value 681113.173 is slightly less than the offset, so essentially the point records build up from there.

From the specs for LAS version 1.2 files:

X, Y, and Z scale factors: The scale factor fields contain a double floating point value that is used to scale the corresponding X, Y, and Z long values within the point records. The corresponding X, Y, and Z scale factor must be multiplied by the X, Y, or Z point record value to get the actual X, Y, or Z coordinate. For example, if the X, Y, and Z coordinates are intended to have two decimal digits, then each scale factor will contain the number 0.01.

For your data, when you scale it (divide the number added to the minimum X bound) by 1000000, it will appear that all points are at the same point - they are separate, but by minute fractions of a meter. They are in the right region because the offset (that does not get scaled) puts them there.

Try to run this without setting scaling - it should leave the defaults in place.

  • las2las --a_srs EPSG:32636 --t_srs EPSG:4326 ../cloud.las -o tmp/p.las error: Y scale and offset combination is insufficient to represent the data – Amit Aug 11 '18 at 16:13
0

Weirdly, this didn't work on my Linux machine, but on a mac even a simpler form does:

las2las -target_epsg 4326 cloud.las -o tmp/p.las

No need to identify my own projection, no need to set a custom scale.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.