Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scanner Channel 0 for single scanner systems #110

Open
nkules opened this issue Apr 26, 2021 · 4 comments
Open

Scanner Channel 0 for single scanner systems #110

nkules opened this issue Apr 26, 2021 · 4 comments

Comments

@nkules
Copy link

nkules commented Apr 26, 2021

I noticed in the current verbiage that it sounds like there is the explicit requirement that all single channel (or single head) systems be set to a scanner channel value of zero:

**"_Scanner Channel
Scanner Channel is used to indicate the channel (scanner head) of a multi- channel system. Channel0 is used for single scanner systems. Up to four channels are supported (0-3).

For Aggregate Model Systems, the Channel should be set to zero unless assigned from a component measurement_**"

I am curious if that is the intent and if we are wanting that to be the case. There are some cases where I can see the interest in using a multi-sensor platform that shares flightline numbers (point source ID) between these single head systems. An example would be flying both a bathymetric and separate topographic sensor (which is no different than a split head but integrated system).

Additionally there may be the case where a vendor has several systems on a project that they want to otherwise denote which system is which within the scanner channel. (e.g. 4 single head systems out flying a singular project). They may already have unique PSIDs but there may be a processing benefit to quickly understand which scanner actually flew which.

Other examples include mobile based systems where the collection may include several independent collection systems on the same vehicle. Alternatively a UAS collection with multiple lidar sensors or an integrated point cloud from both lidar and photometric derived points, where it is beneficial to separate these as difference scanners.

Granted many vendors might opt to use the user byte for this (especially when trying to track multiple multi-channel systems).

I just want to see if the intent is to only support multi-channel or multi-head systems with this field, or leave it more vendor flexible.

@milenajaniec
Copy link

I have seen an instance of this being used for files combining data from green/blue and NIR wavelength channel and sonar data.

Nick, you have pointed out "Additionally there may be the case where a vendor has several systems on a project that they want to otherwise denote which system is which within the scanner channel. (e.g. 4 single head systems out flying a singular project). They may already have unique PSIDs but there may be a processing benefit to quickly understand which scanner actually flew which." This seems to me often to be the case.

@nkules
Copy link
Author

nkules commented Apr 26, 2021

Thanks @milenajaniec for that input. Do you feel from yours or USGS position that it is best to allow these uses or if they should be prescribed to be used in another field?

I also want to be sure that I am reading the current definition as "any single channel system must be set to zero". Also it could be interpreted as channel 0 is only available for single channel systems (and multichannel must use 1-3). Personally I don't read it that way, but I have known others to read it that way.

@rapidlasso
Copy link
Member

rapidlasso commented Apr 27, 2021

The need for discriminating points by "scanner channel" arises when simultaneously operating "laser systems" are generating returns at the same time, because otherwise GPS time stamps are no longer unique and points can not be brought back into a coherent acquisition order per "laser system". This field was originally created when the dual beam systems, such as the RIEGL "crossfire" LMS 1560, the Leica ALS 70 and the Optech Pegasus HA500. became the new workhorses. This 2 bit field also covered the needs of Optech Titan with three lasers operating at different wavelength.

With the arrival of Velodyne, Quanergy, Oyster, ... and there 8, 16, 32, 64 or even 128 simultaneous beams firing in different directions the "scanner channel" is no longer sufficient, which is why we are discussing to store this beam ID as standardized Extra Bytes.

I still find the term "scanner channel" misleading. When recording signals, the term "channels" usually refer to multiple receivers sampling the same signal from different angles (like the two stereo channels), with different sensitivities (like the high and low channel in RIEGL's full waveforms receivers), at different frequencies (red, green, blue receptors), ...

That said, if I had a survey area that gets flown around the same time by three different LiDAR scanners (for example generate a multispectral data set scanned at 532, 1064, and 1550 nm), I might also consider using the "scanner channel" field to distinguish from which laser system each point came from.

@esilvia
Copy link
Member

esilvia commented Jul 13, 2021

I read the spec as written as being descriptive -- "is used" -- rather than prescriptive -- "shall/must be used."

By this interpretation the wording is therefore a suggestion for users to default to Channel 0 rather than, for example, Channel 1 for single-channel sensors. It does not preclude other usages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants