3

I have a relatively simple PDAL pipeline being used to process a bunch of .laz files.

        {
            "type": "readers.las",
            "filename": "c:\\stuff\\10781001.laz"
        },
        {
            "type": "filters.assign",
            "assignment": "Classification[:]=0"
        },
        {
            "type": "filters.elm"
        },
        {
            "type": "filters.outlier"
        },
        {
            "type": "filters.smrf",
            "ignore": "Classification[7:7]",
            "slope": 0.2,
            "window": 16,
            "threshold": 0.45,
            "scalar": 1.2
        },
        {
            "type": "filters.hag"
        },
        ... more stages

It had been chugging along just fine - but eventually crashed. I tracked the error down to the smrf filter - specifically the ignore parameter. In this case, the ignore of classification values of 7 are the noise points identified in the previous pipeline stage (outlier filter). If I remove the ignore parameter from the stage - no errors.

So then I tried to just remove the noise points prior to smrf - but after the outliers stage. This too crashes PDAL:

{
            "type": "filters.range",
            "limits": "Classification![7:7]"
}

So I've saved the laz after the outlier stage. The text below is from lasinfo. Any spot any major issues with this file that may be causing PDAL to crash?

lasinfo (190812) report for 'c:\stuff\10781001.laz'
reporting all LAS header entries:
  file signature:             'LASF'
  file source ID:             0
  global_encoding:            0
  project ID GUID data 1-4:   00000000-0000-0000-0000-000000000000
  version major.minor:        1.2
  system identifier:          'PDAL'
  generating software:        'PDAL 1.9.1 (Releas)'
  file creation day/year:     300/2019
  header size:                227
  offset to point data:       513
  number var. length records: 3
  point data format:          3
  point data record length:   34
  number of point records:    2007
  number of points by return: 1646 311 40 7 3
  scale factor x y z:         0.01 0.01 0.01
  offset x y z:               0 0 0
  min x y z:                  248117.29 3367475.09 61.34
  max x y z:                  248126.86 3367484.89 87.65
WARNING: stored resolution of min_x not compatible with x_offset and x_scale_factor: 248117.29483477573
WARNING: stored resolution of min_y not compatible with y_offset and y_scale_factor: 3367475.0859982171
WARNING: stored resolution of min_z not compatible with z_offset and z_scale_factor: 61.341999999999999
WARNING: stored resolution of max_x not compatible with x_offset and x_scale_factor: 248126.86283477573
WARNING: stored resolution of max_y not compatible with y_offset and y_scale_factor: 3367484.8929982171
WARNING: stored resolution of max_z not compatible with z_offset and z_scale_factor: 87.652999999999992
variable length header record 1 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34735
  length after header  72
  description          'GeoTiff GeoKeyDirectoryTag'
    GeoKeyDirectoryTag version 1.1.0 number of keys 8
      key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
      key 1025 tiff_tag_location 0 count 1 value_offset 1 - GTRasterTypeGeoKey: RasterPixelIsArea
      key 1026 tiff_tag_location 34737 count 21 value_offset 0 - GTCitationGeoKey: NAD83 / UTM zone 15N
      key 2049 tiff_tag_location 34737 count 6 value_offset 21 - GeogCitationGeoKey: NAD83
      key 2054 tiff_tag_location 0 count 1 value_offset 9102 - GeogAngularUnitsGeoKey: Angular_Degree
      key 2062 tiff_tag_location 34736 count 3 value_offset 0 - GeogTOWGS84GeoKey: TOWGS84[0,0,0]
      key 3072 tiff_tag_location 0 count 1 value_offset 26915 - ProjectedCSTypeGeoKey: NAD83 / UTM 15N
      key 3076 tiff_tag_location 0 count 1 value_offset 9001 - ProjLinearUnitsGeoKey: Linear_Meter
variable length header record 2 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34736
  length after header  24
  description          'GeoTiff GeoDoubleParamsTag'
    GeoDoubleParamsTag (number of doubles 3)
      0 0 0 
variable length header record 3 of 3:
  reserved             0
  user ID              'LASF_Projection'
  record ID            34737
  length after header  28
  description          'GeoTiff GeoAsciiParamsTag'
    GeoAsciiParamsTag (number of characters 28)
      NAD83 / UTM zone 15N|NAD83| 
LASzip compression (version 3.4r0 c2 50000): POINT10 2 GPSTIME11 2 RGB12 2
reporting minimum and maximum for all LAS point record entries ...
  X            24811729   24812686
  Y           336747509  336748489
  Z                6134       8765
  intensity           2      35409
  return_number       1          5
  number_of_returns   1          5
  edge_of_flight_line 0          0
  scan_direction_flag 0          0
  classification      0          7
  scan_angle_rank     0          0
  user_data           0          0
  point_source_ID     1          2
  gps_time 79997.732018 80500.322163
  Color R 5355 64770
        G 20910 64770
        B 17595 64770
WARNING: 1 points outside of header bounding box
number of first returns:        1646
number of intermediate returns: 40
number of last returns:         1730
number of single returns:       1409
overview over number of returns of given pulse: 1409 499 74 18 7 0 0
histogram of classification of points:
            1928  never classified (0)
              79  noise (7)
WARNING: real min x smaller than header min x by 0.004835
  • Can you post the file that crashes somewhere I can get it to test? – Howard Butler Oct 30 '19 at 1:03
  • Hi Howard. Here is link:drive.google.com/open?id=1SOw1ZbKAxk2DSzJYVFfrJ--rzVcpCBDZ One quick note... The .laz file as delivered to me has no CRS defined. It is in UTM Zone 15N EPSG 26915. In the first stage of my pipeline - I do have it specified there – user890 Oct 30 '19 at 14:23
3

This file is strange.

First, an EPSG code of 0 isn't valid.

LOCAL_CS["unnamed",AUTHORITY["EPSG","0"]]

Second, SMRF is designed for aerial LiDAR data, not this (bridge superstructure?).

point file

Third, there's a bug in the SMRF knn code that is triggered by this particular point configuration. Please follow https://github.com/PDAL/PDAL/issues/2794 for details.

| improve this answer | |

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.