if the resulting LAZ file would not contain any information how the pixels are organized you would be right: Then we would need a definition what each pixel means.
But within the resulting LAZ file we have the same pixel information as we have in the GeoTIFF input file.
Using geotiffinfo we get the source pixel information
geotiffinfo64 -i jj_pixelisPoint.tif
...
KeyID Loc Cnt Value: KeyDesc = Value
1024 0 1 1: GTModelTypeGeoKey = ModelTypeProjected
1025 0 1 2: GTRasterTypeGeoKey = RasterPixelIsPoint
...
geotiffinfo64 -i jj_pixelisArea.tif
...
KeyID Loc Cnt Value: KeyDesc = Value
1024 0 1 1: GTModelTypeGeoKey = ModelTypeProjected
1025 0 1 1: GTRasterTypeGeoKey = RasterPixelIsArea
...
Then we do the RasterLAZ conversion
demzip64 -i jj_pixelisPoint.tif -o tmp_p.laz
demzip64 -i jj_pixelisArea.tif -o tmp_a.laz
and check the output files:
lasinfo64 -i tmp_p.laz
lasinfo64 -i tmp_a.laz
We get the same key values as we have in the input files:
LAStools lasinfo (by
in...@rapidlasso.de) version 251223
reading 'tmp_p.laz' with 644 points
...
GeoKeyDirectoryTag version 1.1.0 number of keys 5
key 1024 tiff_tag_location 0 count 1 value_offset 1 - GTModelTypeGeoKey: ModelTypeProjected
key 1025 tiff_tag_location 0 count 1 value_offset 2 - GTRasterTypeGeoKey: RasterPixelIsPoint
...
...
key 1025 tiff_tag_location 0 count 1 value_offset 2 - GTRasterTypeGeoKey: RasterPixelIsArea
...
So we think this is the way it should work.
If you have a TIF with GTRasterTypeGeoKey = RasterPixelIsPoint but you want to have your output as Raster LAZ with PixelIsArea you easy can change your input file to the required pixel type using gdal:
gdal_edit.exe -mo AREA_OR_POINT=Area file_to_change.tif