Why this sonar trajectory is wiggly and its speed changes so fast？

[ldr426]

Hi, mentors, just found something werid.
When plotted on map, the OOI sonar trajectory is very wiggly.

Then I tried caculating speeds for every location_time interval. I was surprised by the outcome.
I don't know why speed changes so dramatically, like from 50m/s to 1m/s in very short time(less than 1s).
That is normal for an sonar?

This is how I caculate speed. I use method distance(WGS-84) to transform (lat, lon) tuples to distance(units:km),
WGS-84 medthod in this function just results in an error of up to about 0.5%.

dis=distance.distance(tuple([previous_lat,previous_lon]), tuple([current_lat,current_lon])).km*1000
time_delta=(current_time- previous_time).total_seconds()
speed=dis/time_delta

[leewujung]

@ldr426 : is this trajectory from OOI? OOI data are moorings (fixed instruments deployed somewhere in the ocean) so would not move. My guess is that this data are from the hake survey?

I know that for some of these data, there are multiple NMEA "sentences" that actually have different resolutions. Could you print out a corresponding section in the Platform group (EchoData.platform. sentence_type) and check what's in there? I remember having to not select the "RMA" (or "RMC," I forgot which) datagram because those returns coarser lat/lon values (which results in the interleaving patterns you saw).

One background info is that the NMEA data stream came from another instrument (usually something with a GPS in it) that was plugged in into the sonar. The sonar in this case is just recording everything in.

[ldr426]

Ok, thanks Ms @leewujung. 😄

My guess is that this data are from the hake survey

Yeah, this data is from the hake survey. I said wrong OOI echosounder belongs to moving echosounder.

print out a corresponding section in the Platform group (EchoData.platform. sentence_type) and check what's in there?

Below is the section in the EchoData.platform. sentence_type. GGA occurs twice then GLL occurs once periodically.

Q1

So different interpreted sentences which occur periodically result in interleaving patterns?

Q2

Does calculating moving platforms speed make any sense for scientific analysis?

Q3

So far, it has been only two types of sonar data we are dealing with. Is there a third?
(One is 🚢 moving echosounder like Hake survey, another is moored echosouder which is fixed somewhere.

Q4

#17 (comment) is only for moored echosouder?
#26 & #18 are only for moored echosouder?
#20 (comment) for both echosouders?

[leewujung]

@ldr426 :

So different interpreted sentences which occur periodically result in interleaving patterns?

Based on what you printed out on the 2xGGA + 1xGLL pattern and how the ship track looks like in your previous plot, I suspect that if you select only the GGA positions, the line may come out smooth. This is interesting, I had not zoomed in to this level to see this anomaly and we should do something about it in #26.

Does calculating moving platforms speed make any sense for scientific analysis?

I think this depends on the analysis one is interested in, but in general, the speed of the ship does tell something about what the ship might be doing (transit would be fast, deploying a mooring would be slow/very slow, etc).

Going on a tangent here -- I had led a project in OceanHackWeek to try to auto-segment the shiptrack. The project was unfinished given the limited time but I am interested in reviving it at some point. 😀

So far, it has been only two types of sonar data we are dealing with. Is there a third?
(One is 🚢 moving echosounder like Hake survey, another is moored echosouder which is fixed somewhere.

In terms of how the platform moves, these two types are the most general. There can be lots of other possible combinations, like putting an echosounder on a profiler (a package that goes up and down the water column), but not as common. Another type I think is useful to develop is an extension of the moving ship type, but adding a depth dimension in the movements, from some kind of underwater vehicle. I have some data from a glider that we can play with for that also.

#17 (comment) is only for moored echosouder?

Not necessarily. Similar type of data can come from ships also, but from a moored echosounder the data does not need to be organized again with the movements or seeing the seafloor.

#26 & #18 are only for moored echosouder?

#26 would be data from a moving platform.

#20 (comment) for both echosouders?

Yes, this is a general one that is pretty flexible and other statistics can be explored in the visualization also.

[ldr426]

Ms @leewujung, that is useful answers :)

I had not zoomed in to this level to see this anomaly and we should do something about it in #26.

I found that problem also. Sometimes the interweaving pattern could also appear in 3D curtain. Just like you said, taking only one interpreted sentence is a way to smooth the line.

Another type I think is useful to develop is an extension of the moving ship type, but adding a depth dimension in the movements, from some kind of underwater vehicle.

Once the data with a depth dimension is put in echopype, then we could develop that extension. My idea is plotting the track line above the echogram or 3D curtain, just like something below:

[leewujung]

@ldr426 : It's awesome to see the curtains!

Sometimes the interweaving pattern could also appear in 3D curtain.

Yes, if the GPS track is wiggly, the 3D curtain will be the same way. Whether or not we "see" it though is probably a question of resolution. When zoomed out (like what I was doing, to look at the ship track across a few days), these would be hard to see.

Just like you said, taking only one interpreted sentence is a way to smooth the line.

If PyVista does not have that in some automated form already, something can probably be done to resample the mesh when users are in a more zoomed out view. Not sure how fast this would be though. It may be useful to smooth and subsample from the Sv dataset first before constructing a mesh.

[leewujung]

Once the data with a depth dimension is put in echopype, then we could develop that extension. My idea is plotting the track line above the echogram or 3D curtain

Yep! Perhaps an option to toggle on and off the curtain in this case, so that there's also a 3D trajectory only view in the space.

[leewujung]

We can close this now since the issue itself is resolved: there are multiple NMEA sentence types in the GPS, and we should select one to interpolate the lat/lon locations on to the Sv or MVBS data.

Note:

• currently the echopype add_location function does this interpolation for Sv data
• However, the compute_MVBS function discards the interpolated lat/lon locations (documented in compute_MVBS should propagate and bin average Sv latitude and longitude, and depth/water_level echopype#1002) and this has to be fixed.