Pulsewaves and Riegl MTA zone

[Antoine Cottin]

Hi Martin,

One of Riegl's engineer just point out to me that Pulsewaves is not MTA compatible, meaning that if the MTA is not 1, then the data will look skewed in Pulseview and in any processing that involve coordinates calculation for the peaks !

Do you confirm that Pulsewaves is not MTA ready.

For completeness of the discussion, here is the post from Riegl as well as the images.

Cheers

Antoine

Rielg's post:

Anyway, the file looks like the screenshot render_first_return.tiff you sent.
My file: [RiPROCESS.png]
Using pulseview it looks like [PulseView1.png] which seems to be ok. 
You will NOT see something like RiPROCESS shows.
The data was collected in MTA zone 2 and since PulseWaves is not MTA resolved
pulseview shows the data in MTA zone 1 containing jittering (and all flying
points) [Waveforms1.png].

[Martin Isenburg]

Hello Günther and Martin (in bcc),

This sounds like a question for you to answer. It is my understanding that the MTA analysis happens in RiMTA (or so) and that happens before (or during) the RiPROCESS export so that the correct zone should be known already by the time the PulseWaves export actually happens ...

Martin @rapidlasso

--
--
Post to "PulseWaves" by email to pulse...@googlegroups.com
Unsubscribe by email to pulsewaves+...@googlegroups.com
Visit this group's message archives at http://pulsewaves.org

---
You received this message because you are subscribed to the Google Groups "PulseWaves - no pulse left behind" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pulsewaves+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[luhao.rs]

Hi guys,

In my understanding, the point cloud and waveform exported by RiPROCESS have different concepts concerning the MTA zone issue.

The MTA analysis is done in RiANALYZE(may be with RiMTA module). The decomposition of the raw waveform have considered the range ambiguity issue in RiANALYZE and RiMTA. It has nothing to do with the output points because the points are geocoded only after waveform decomposition and when the laser ranges are known.

So, if you use the point cloud exported by RiPROCESS and see skewed points, well, it is the fault of RiANALYZE. In this case you should consult your data provider and ask them to fix this by assigning a correct MTA zone or use RiMTA module. The difference between RiANALYZE and RiMTA is the latter has implemented an automatic range ambiguity resolution method and can solve the problem in your pictures without any manual interactions.

If you can see skewed points or waveforms in PulseView, then my conclusion would be that when RiPROCESS exports the PulseWave format, it just exports all the waveform sample blocks as WHAT IT LOOKS LIKE, I mean, it didn't consider the range ambiguity problem as RiMTA does. My suggestion for Martin is refering to a paper by Dr. Peter Rieger named <Range ambiguity resolution technique applying pulse-position modulation in time-of-flight scanning lidar applications>. It explained how RIEGL did in LMS Q-680i and newer systems in solving the "skewed" problem as well as the algorithm in RiMTA.

Cheers,

---

Hao

[Roland Schwarz]

On 11.11.2014 08:23, wrote luhao.rs:

...

If you can see skewed points or waveforms in PulseView, then my conclusion would be that when RiPROCESS exports the PulseWave format, it just exports all the waveform sample blocks as WHAT IT LOOKS LIKE, I mean, it didn't consider the range ambiguity problem ...

This is correct, and this reflects a problem with the current definition of the PulseWaves format. As a consequence we decided to convey as much original data as possible without doing interpretation (such as MTA resolution). Obviously this is not what a user expects. We will discuss with Martin, which changes might be possible.

Best regards,
Roland

-- 
DI Roland Schwarz
Sen. Eng. / SW Dev.
RIEGL LMS GmbH
Millenium Tower, Handelskai 94-96
A-1200 VIENNA, AUSTRIA
Phone: +43 2982 4211
Fax: +43 2982 4210
email: Roland....@riegl.co.at
www: http://www.riegl.com

---

RIEGL Laser Measurement Systems GmbH
Riedenburgstrasse 48, 3580 Horn, Austria
Registered at Landesgericht Krems, FN 40233 t

---

Disclaimer

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. In that case please notify us by return email, and erase all copies of the message and attachments. Thank you. RIEGL reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus- free and the company does not accept liability or responsibility for such matters or the consequences thereof.

[Martin Isenburg]

Interesting discussion ...

> [...] this reflects a problem with the current definition of the PulseWaves format. [...]

Could you elaborate how the issue of improper or incomplete MTA resolution can be considered are a problem of the definition of the PulseWaves format? The PulseWaves format - just like the LAS format - was not designed to have a "feature" that allows to express ambiguities in the MTA zone. Maybe it should?

In my originally intended meaning of PulseWaves, the format was not meant to provide a mechanism to defer MTA issues to the end user. Just like those issues are resolved prior to exporting points to the LAS format, I was expecting this to be always resolved prior to export. And in the many discussions we had about the format this issue was not brought up once, so it never came up for consideration.

Should correct MTA resolvment be responsibility of the hardware manufacturer (i.e. operate at a  sufficiently low pulse repetition rate to guarantee correct MTA resolution) exporting PulseWaves ... ?

Or should post processing of MTA zones be one of the "features" of using PulseWaves because it - as an example - would allow to scan at much-higher-than-manufacture-recommended pulse repetition rates above complex terrain and give the advanced user the option to use the PulseWaves API to do fancy post-processing (outside the manufacturers software suite) to resolve where the waveforms of the two lasers of the "crossfire" have hit a grand-canyon-style landscape below at 400 kHz each ... ?

Martin

[Antoine Cottin]

Hello Martin,

Any update on this from Riegl ?

cheers

Antoine

[Roland Schwarz]

Am 24.11.2014 12:15, schrieb Antoine Cottin:

Hello Martin,

Any update on this from Riegl ?

Hi Antoine!

Martin was asking what processing of MTA zones should look like: data producer or data consumer.
We intend to do what customers need. For the time beeing we implemented the "data consumer" way of doing things i.e. expect user code to do MTA resolution.

But I just filed a ticket to our developers to implement the other method, where we will put the waves into already resolved MTA zone. However this cannot be done unambiguously and may result into multiple export of the same waveform when the MTA resolver found that a single wave contained echoes from different zones.

Having said this, we at Riegl still would like to learn what customers do expect really.

Regards,

[Antoine Cottin]

Good new for Pulsewaves ;)

According to Riegl, the next release of RiProcess will have this issue address and the exporter should take care of the MTA.

A-

[nayaniil...@boisestate.edu]

Hi,

I have another question.

I used Riprocess and every time it gave me terrain data that is one MTA zone above the actual terrain heights. I have to shift the data. Do any of you have experienced that or any opinion whats going on there?

Thanks,

Nayani