6
This is a consequence of sf now working with spherical geometry by default. The real straight line between the two top corner points of your rectangle are great circles, which will be bulging north.
Switch that off and sf will assume lat-long is planar and you get the result you expected:
> sf_use_s2(FALSE)
Spherical geometry (s2) switched off
> ...
2
You should be able to read this using the sf package as a vector data source.
Extracting the ZIP file of the chart I think you are referencing gets me a US5MD23M.000 file. With sf package I can see its lots of layers:
> st_layers("US5MD23M.000")
Driver: S57
Available layers:
layer_name geometry_type features fields
1 DSID ...
1
Well, I think you are overthinking the problem.
Considering what I'm understanding of your problem I can't see any problem. In lidR rasters are always properly aligned according to a reference point (start parameter) and the extent of the point cloud does not matter. The grid is snapped and slightly extended to be aligned. No possible misalignment.
If you ...
1
sunAngle args are longitude, latitude:
Usage:
sunAngle(t, longitude = 0, latitude = 0, useRefraction = FALSE)
You called sunAngle(t, lat, long) which is the wrong way round, and R doesn't know what your variables are named, it matches them with the args of sunAngle by position.
Either name them, in which case you can do them any way round, or do them ...
1
With a little trial and error, I found that this works:
lidar_first = filter_poi(lidar, ReturnNumber == NumberOfReturns)
The list of potential select attributes for readLAS in the documentation gave me the hint that there might be a variable NumberOfReturns available (there it is called r - number of returns). However I haven't found any explicit hints on ...
Only top voted, non community-wiki answers of a minimum length are eligible