4 ms·

You could have a local copy onboard. There should be enough rack space on the boat to keep a copy that gets updated when the boat gets connected to shore data.

You could have a local copy onboard. There should be enough rack space on the boat to keep a copy that gets updated when the boat gets connected to shore data. Also for sea data, the data set would be much smaller because it hardly changes, and you don't have as many variables(i.e. live traffic, construction, etc), especially under the sea.

jjk166 5y ago
I don't agree that the data set would be much smaller. Maps for driving may look complicated, but they're just weighted graphs. You might have a few different data points for MLK drive like length, average traffic, speed limit, class of road, etc, and these values might even be given for each short stretch of the road, but you don't have to have any knowledge of the actual topography, and all of these values can be safely taken as rough estimates. No one is going to die if you falsely classify a stretch of road as high traffic when it's really moderate. For a submarine, you need to know the topography of the sea floor down to meter scales. Accurate maps are few and far between, and difficult to create. Changing currents, underwater landslides, silt from rivers, sunken wreckage and even just garbage can create and move obstacles large enough for a submarine to care about in relatively short timeframes. Of course submarines can and do navigate with maps prepared ahead of time, but it's tough, and every now and then you get a run in with a sea mount.
- trcarney 5y ago
  I agree the undersea landscape can change dynamically but there is no way to do undersea data transmissions of the size required to do live updates. I guess what I meant is a sub should be able to have a more modern solution onboard because it wouldn’t take up much space on board which is a massive consideration for things like this. Even if the data set is huge, you should be able to fit the system and a redundant system in a full rack. When I was on a surface ship, our entire nav system fit on a single server with an additional server as a backup. Our system could be updated live because we had internet on board. Subs don’t have this luxury so they would need the full dataset on board.

jjk166 5y ago

I don't agree that the data set would be much smaller. Maps for driving may look complicated, but they're just weighted graphs. You might have a few different data points for MLK drive like length, average traffic, speed limit, class of road, etc, and these values might even be given for each short stretch of the road, but you don't have to have any knowledge of the actual topography, and all of these values can be safely taken as rough estimates. No one is going to die if you falsely classify a stretch of road as high traffic when it's really moderate. For a submarine, you need to know the topography of the sea floor down to meter scales. Accurate maps are few and far between, and difficult to create. Changing currents, underwater landslides, silt from rivers, sunken wreckage and even just garbage can create and move obstacles large enough for a submarine to care about in relatively short timeframes. Of course submarines can and do navigate with maps prepared ahead of time, but it's tough, and every now and then you get a run in with a sea mount.

trcarney 5y ago
I agree the undersea landscape can change dynamically but there is no way to do undersea data transmissions of the size required to do live updates. I guess what I meant is a sub should be able to have a more modern solution onboard because it wouldn’t take up much space on board which is a massive consideration for things like this. Even if the data set is huge, you should be able to fit the system and a redundant system in a full rack. When I was on a surface ship, our entire nav system fit on a single server with an additional server as a backup. Our system could be updated live because we had internet on board. Subs don’t have this luxury so they would need the full dataset on board.