[DEV][0.24.x][Jul 24] SCANsat v7.0rc4 -- Real Scanning, Real Science, at Warp Speed!

[DMagic]

There are a few things to keep in mind:

ORS scanners have no recording function, they only display the resources below your current position and display the little texture icons on a portion of the planet. To have any integration with SCANsat additional part modules are required.

I'm using slightly different versions of the SCANsat module (with the resourceType field), which clutters up the persistent file a little bit more, but doesn't require any changes to the regular SCANsat scanners. It's surely possible to accomplish ORS scanning and background scanning some other way, but it seems best to build on the method we already have.

For Kethane it is possible to use only the existing Kethane detectors and only pull information out of the Kethane database for generating the SCANsat overlay. The biggest problem with this is that it is very slow. Converting from position in latitude/longitude (which is how the maps are generated) to Kethane cells is slow, and when you need to do it tens of thousands to several million times per map reset it can really bog things down.

The best solution seems to be adding our own part modules to the Kethane detectors and handling everything on the SCANsat side. There are still a few problems, one is that we need to pull the amount of resources in each deposit out of the Kethane database, and that we need to be able to update the SCANsat database with already existing Kethane scans (and to do the reverse for background scanning).

The ORS method for checking how many resources each point on the map has is very quick, but the Kethane method is still somewhat slow (it requires at least some amount of converting positions to Kethane cells). There might be a way of simplifying this. Kethane is found in a small number of deposits on each planet, each with a fixed amount of resources, so it seems like there should be some way of getting around the Kethane cell problem and just directly reading out the amount of resources remaining in each deposit. As of yet I have no idea how to do that though.

[Tessai]

I don't know how feasible it is, but now the only thing I am missing for ORS to be as easy to use as kethane would be the ability to project the ORS overlay back onto the planet (like the kethane grid).

[phoenix_ca]

I don't know how feasible it is, but now the only thing I am missing for ORS to be as easy to use as kethane would be the ability to project the ORS overlay back onto the planet (like the kethane grid).

See the OP. There are pictures.

[IronGremlin]

So, sorry to play armchair coder, but I can't resist the suggestion:

What about generating full map files for each save with your own logic - basically parsing the information directly from kethane persistence files and exporting it to a format that you can read with scansat? Then there is no need to check latitude against a specific hex.

It wouldn't look pretty, and the default kethane overlay wouldn't be discovered by your scan, but you'd get useable information out of a scan that could be run in the background... It could be an acceptable compromise for many players.

[technogeeky]

So, sorry to play armchair coder, but I can't resist the suggestion:

What about generating full map files for each save with your own logic - basically parsing the information directly from kethane persistence files and exporting it to a format that you can read with scansat? Then there is no need to check latitude against a specific hex.

It wouldn't look pretty, and the default kethane overlay wouldn't be discovered by your scan, but you'd get useable information out of a scan that could be run in the background... It could be an acceptable compromise for many players.

This sounds naive to me.

Where do we store the new data? If it's in persistent.sfs, then we'll double the amount of data SCANsat stores everywhere, needlessly. If it's not in persistent.sfs, we become responsible for maintaining synchronization with wherever we are storing the data and the user's game. This sounds easy, until it messes up.

We'll find a solution, but it will be a deliberate one.

[DMagic]

This is still far from being ready, but my new method seems to be working, or at least sort-of working. This uses a separate assembly to interface with Kethane. It mostly just watches for changes made to the SCANsat UI (ie pushing buttons on the screen) and sends data to SCANsat when needed.

I'm getting around the performance hangups by intentionally slowing down some methods. It takes about nine seconds to read out data from Kethane's database and send it to SCANsat, which should only be necessary when loading or switch to a new planet. The process is slow enough that it doesn't seem to affect KSP. When the big map is rebuilt it is only necessary to update the resource values for each cell, which seems to be quicker, so I just run that at the same time the map rebuilds. This might cause problems if the map builds too quickly though, this all needs much more testing and tweaking.

There is still some mismatch between what SCANsat is recording and what the Kethane grid is displaying, I think it has something to do with the offset values being used for long/lat. And I'm still not sure why the SCANsat side of things is giving spotty results, rather than the continuous bands that the regular SCANsat scanners produce.

The results look basically the same as the old versions. You can see some of the mismatch here.

[Mecripp]

I can't get the big map to show up debug just shows ArgumentOutOfRangeException: Argument is out of range little map works and the rest.

Edit And when, I click the big map button the mod void go's off screen click it again and void is back on screen maybe they don't want to play.

Edit 2-- Ok did alittle check void has a turn off on screen with it off screen, I can get the big map to come up, so they don't like to play nice.

Edited May 22, 2014 by Mecripp2

[Psawhn]

That looks amazing! Back when ISA_Mapsat was a thing, I'd have to manually use GIS to overlay Kethane maps onto height maps to find good landing sites. Having SCANsat do that is an incredibly useful tool.

On the subject, though, I'd be wary of duplicating or even obsoleting scanning functionality of existing mods like Kethane. I think I'd read that Majir has specific design goals in mind for Kethane, and the reason he hasn't implemented unfocused scanning on his own is that he still wants electric charge power management to be an important factor in Kethane scanning. Implementing a SCANsat Kethane scanner that can scan at higher time warps without focus on the vessel... oh and it can scan in a 45 degree cone for less electric charge... that's a bit rude, now, ain't it?

Is it too early to talk about possible changes in SCANsat's FOV mechanics for v8 (or later) yet? . Personally, I'd think it'd be amazing if the SAR and Multispectral scanners had similar behaviour and swath widths under RSS as real systems like LANDSAT and RADARSAT have in real-life.

In addition, ideally each sensor type would have its own scanning behaviour. RAR (real-aperture RADAR) would work as it does now, scanning in a box around the vessel's position to represent manually steering it in two directions. Multispectral would scan in a line perpendicularly to its ground travel to represent a Scanning or Pushbroom style radiometer. Finally, SAR would scan perpendicularly to the direction of travel, but only to one side (and not directly underneath) because of how synthetic-aperture RADAR works.

I think that'd be a fun concession to realism that'd make GIS nerds like me or RSS gurus like NathanKell happy .

[phoenix_ca]

*eyetwitch* That's...four different processes for determining scan area? ... I can't speak for DMagic nor Technogeeky, but I sure wouldn't want to maintain four very different methods of doing what amounts to the same thing. O.o

As for Majiir and Kethane, he's said that he was open to suggestions to do background scanning and such. DMagic just kinda...showed him up a little by whipping together a solution in under an hour using SCANsat.

[technogeeky]

DMagic:

As a first step to approaching color problems, I have refactored all references to colors, XKCDcolors, color interpolation, etc -- into SCANpalette.cs.

I have added this in a new branch and merged it with dev.

Let me know if this gets in your way; I will revert it from dev.

[DMagic]

*eyetwitch* That's...four different processes for determining scan area? ... I can't speak for DMagic nor Technogeeky, but I sure wouldn't want to maintain four very different methods of doing what amounts to the same thing. O.o

Yeah, the end result would seem to be about the same. The offset scanning coverage would be slightly different, though it would probably just confuse the majority of users and would only be noticeable if you actually watch it scan. And also, scanning under high time warp relies on the high FOV creating a box around the vessel position to fill in the map without gaps. If we switched to a much narrower scan in one dimension it would complicate that.

As for Majiir and Kethane, he's said that he was open to suggestions to do background scanning and such. DMagic just kinda...showed him up a little by whipping together a solution in under an hour using SCANsat.

The only two reasons I've seen given are the electricity use and the technical complications of determining which Kethane cell is being scanned from an inactive vessel (high timewarp is a big factor here too). SCANsat ignores electricity for inactive vessels, and I'm not aware of anyone who know how to accurately do this with reasonably performance anyway, calculating solar panel electricity for an inactive vessel doesn't sound simple. Electricity is a problem even for active vessels at very high timewarps because of the errors in calculations of power usage vs power generation, SCANsat just ignores it at over 1000x timewarp.

As for the technical complications, I think that's only a problem if you are trying to plot which cells fall under the vessel's orbit at any given time. If you just ignore all of that and only record which positions the vessel flies over (in lat/long) you can rely on the wide FOV to fill in any gaps and worry about Kethane cells later.

[phoenix_ca]

As a first step to approaching color problems, I have refactored all references to colors, XKCDcolors, color interpolation, etc -- into SCANpalette.cs.

Any thoughts on using a config node for colours? It could make providing colourblind support easy-peasy. (I'm mentioning colourblind support because this is, to my knowledge, the only mod that actually depends on colour differentiation to convey information, which seems to be a special case far in KSP.) That and colour customization. (Or maybe that's not the best solution. Perhaps an XML file? Or straight-up JSON if possible and you're feeling generous. )

[technogeeky]

That looks amazing! Back when ISA_Mapsat was a thing, I'd have to manually use GIS to overlay Kethane maps onto height maps to find good landing sites. Having SCANsat do that is an incredibly useful tool.

On the subject, though, I'd be wary of duplicating or even obsoleting scanning functionality of existing mods like Kethane. I think I'd read that Majir has specific design goals in mind for Kethane, and the reason he hasn't implemented unfocused scanning on his own is that he still wants electric charge power management to be an important factor in Kethane scanning. Implementing a SCANsat Kethane scanner that can scan at higher time warps without focus on the vessel... oh and it can scan in a 45 degree cone for less electric charge... that's a bit rude, now, ain't it?

I don't think we intend to act unilaterally. Just as we have left in somewhat arbitrary settings for SCANsat scanners (where I might think they should be adjusted), we will respect the gameplay intentions of other mods to the extent we can.

As for electric charge usage -- this is a realism point that needs to be addressed.

My only guess at how to handle it would be:

• calculate in the active vessel how large of a battery buffer would be required to survive X scan type at Y warp factor
  
• for each background scanner
  
  • if their panels are deployed and/or their RTGs are actived and:
    
  • their battery buffer is large enough, allow them to contribute
    
  • otherwise, disallow contribution and warn
    

Additionally, if/once we implement a day/night terminator we would be able to more precisely determine if the buffer would suffice. Modulo different orbital parameters, this should be nearly trivial to estimate.

So even if we don't drain the resource from an inactive vessel, at least we can ensure that it would have had enough charge had we used that vessel as active.

NathanKell says that you *can* drain the resource from an inactive vessel, too.

I don't actually know if we can ask about panel deployment state or battery capacity. I suspect we can.

Is it too early to talk about possible changes in SCANsat's FOV mechanics for v8 (or later) yet? . Personally, I'd think it'd be amazing if the SAR and Multispectral scanners had similar behaviour and swath widths under RSS as real systems like LANDSAT and RADARSAT have in real-life.

NathanKell and I have discussed this today. There are a few known location where SCANsat hardcodes values which (relatively) hurt the utility of SCANsat in RSS. Nevertheless, thousands of people use RSS and we want them to use SCANsat, so they are a relatively high priority.

To me, that is not only the obvious place to start to calibrate the FOVs and swath widths of scanners in RSS; it is also a good way to determine the realism level of scanners in the Kerbol system. I would be happy have someone to summarize the orbits used and the total scanning time needed and see how these scanners compare.

In addition, ideally each sensor type would have its own scanning behaviour. RAR (real-aperture RADAR) would work as it does now, scanning in a box around the vessel's position to represent manually steering it in two directions. Multispectral would scan in a line perpendicularly to its ground travel to represent a Scanning or Pushbroom style radiometer. Finally, SAR would scan perpendicularly to the direction of travel, but only to one side (and not directly underneath) because of how synthetic-aperture RADAR works.

You've mentioned this before. For SAR, we would essentially cut the swath width in half and offset it to not be centered? (or leave the width the same but make it offset)?

My favorite pet project in new scanners lies in satellites that require multiple vessels to provide any data (ala GRAIL or RBSP). In other words, scanning 3D volumes instead of surfaces. This, of course, is probably very difficult and all of the data would need to be implemented by us.

I think that'd be a fun concession to realism that'd make GIS nerds like me or RSS gurus like NathanKell happy .

NERDS!

[technogeeky]

Any thoughts on using a config node for colours? It could make providing colourblind support easy-peasy. (I'm mentioning colourblind support because this is, to my knowledge, the only mod that actually depends on colour differentiation to convey information, which seems to be a special case far in KSP.) That and colour customization. (Or maybe that's not the best solution. Perhaps an XML file? Or straight-up JSON if possible and you're feeling generous. )

I don't know about where I intend to store color information; but I'll figure it out in a day or two. I'll probably store a string of HTML/hex colors if I put it in persistent -- I don't want to introduce as many fields as we have currently used colors.

The existing colors for some maps are already (supposedly, I haven't verified yet) colorblind safe. However, some of the UI element colors are not. This is a known bug and will be fixed by v8, and will be tested in v7.

I was intending to mimic the coloration techniques used by d3.js; but it turns out they just referenced this very cool site. Since it already has colorblind-safe coloration palettes... I don't see why I shouldn't steal them all! And offer them as options!

[technogeeky]

I can't get the big map to show up debug just shows ArgumentOutOfRangeException: Argument is out of range little map works and the rest.

Edit And when, I click the big map button the mod void go's off screen click it again and void is back on screen maybe they don't want to play.

Edit 2-- Ok did alittle check void has a turn off on screen with it off screen, I can get the big map to come up, so they don't like to play nice.

Can you edit this to be more coherent, and perhaps include screenshots? It's hard to understand what your edits mean relative to your first post.

[JeffreyCor]

Inactive ship scanning of Kethane and such resources alone has me sold on v7 That would even be worth a restart if it was save breaking!

[Mecripp]

Can you edit this to be more coherent, and perhaps include screenshots? It's hard to understand what your edits mean relative to your first post.

Void has a on screen display, When first try'ed to open big map it didn't open and it took void off screen and, I got that error so, I then went back to game forgot void as a turn off display on the toolbar icon so, I turned it off and then try'ed the big map and it worked so then turn void back on to see an now it all works maybe it was a 1 time deal ?

[Psawhn]

Yeah, the end result would seem to be about the same. The offset scanning coverage would be slightly different, though it would probably just confuse the majority of users and would only be noticeable if you actually watch it scan. And also, scanning under high time warp relies on the high FOV creating a box around the vessel position to fill in the map without gaps. If we switched to a much narrower scan in one dimension it would complicate that.

Which is fair. I realized shortly after posting that the box fill gives the buffer for higher time warps. Plus, the effects not being noticeable is a relevant point.

I'd still think having SAR scan only to one side would be an interesting concession to reality.

Although, thinking about it, there's already orbit prediction code in place, right? It's used to draw the orbit tracks. I wonder if it's possible to repurpose it to update the map by interpolating updates on scanning knowledge between its last known position and its current position. That may not be a bad idea for a long-term goal. Not only should this allow for arbitrarily large time-warps, but also for unfocused scanning around SOIs other than the current body.

[technogeeky]

Which is fair. I realized shortly after posting that the box fill gives the buffer for higher time warps. Plus, the effects not being noticeable is a relevant point.

I'd still think having SAR scan only to one side would be an interesting concession to reality.

Although, thinking about it, there's already orbit prediction code in place, right? It's used to draw the orbit tracks. I wonder if it's possible to repurpose it to update the map by interpolating updates on scanning knowledge between its last known position and its current position. That may not be a bad idea for a long-term goal. Not only should this allow for arbitrarily large time-warps, but also for unfocused scanning around SOIs other than the current body.

Orbit projection doesn't work like I expected it to. I had those screenshots of me playing with it. What I found is that it was happy to project backwards, but would only project one orbit forwards.

This could have been the way I was doing it, though. *shrug*

It's on the list anyway. I want a line-based orbit projection (for projecting into the far future), a fixed-dot-sized orbit projection (like the current implementation) for projecting the next and previous orbit with a sense of velocity; and a variable-sized-dot orbit projection (with low opacity) to show the swath width of each active scanner.

[DMagic]

DMagic:

As a first step to approaching color problems, I have refactored all references to colors, XKCDcolors, color interpolation, etc -- into SCANpalette.cs.

I have added this in a new branch and merged it with dev.

Let me know if this gets in your way; I will revert it from dev.

I integrated my changes with yours. I think I got everything in right, though I had to rely on VS to catch some errors. The dev branch has the color palette updated version, the v7 branch has the non-color palatte version. Neither is ready for distribution.

[Psawhn]

As for electric charge usage -- this is a realism point that needs to be addressed.

My only guess at how to handle it would be:

• calculate in the active vessel how large of a battery buffer would be required to survive X scan type at Y warp factor
  
• for each background scanner
  
  • if their panels are deployed and/or their RTGs are actived and:
    
  • their battery buffer is large enough, allow them to contribute
    
  • otherwise, disallow contribution and warn
    

Additionally, if/once we implement a day/night terminator we would be able to more precisely determine if the buffer would suffice. Modulo different orbital parameters, this should be nearly trivial to estimate.

So even if we don't drain the resource from an inactive vessel, at least we can ensure that it would have had enough charge had we used that vessel as active.

NathanKell says that you *can* drain the resource from an inactive vessel, too.

I don't actually know if we can ask about panel deployment state or battery capacity. I suspect we can.

That sounds like a good plan. I'd be worried about the uncertainty of electric generation. Solar panel geometry, extra generators like KSPI's or Kethane's, or extra sinks like RT2 antennas, complicate the solution. Personally, I don't mind the assumption that unfocused vessels have enough generators/batteries to last through the nights just because the alternative is such a potential mess.

NathanKell and I have discussed this today. There are a few known location where SCANsat hardcodes values which (relatively) hurt the utility of SCANsat in RSS. Nevertheless, thousands of people use RSS and we want them to use SCANsat, so they are a relatively high priority.

To me, that is not only the obvious place to start to calibrate the FOVs and swath widths of scanners in RSS; it is also a good way to determine the realism level of scanners in the Kerbol system. I would be happy have someone to summarize the orbits used and the total scanning time needed and see how these scanners compare.

If you'd like, I can summarize some of the stats for some of the real Earth-Observation satellites.

[sAR sidelook]You've mentioned this before. For SAR, we would essentially cut the swathwidth in half and offset it to not be centered? (or leave the width the same but make it offset)?

Mostly just leave the swath width, then offset that. The neat thing is that it shouldn't affect time-to-scan or trying to line up sidelaps or coverage, because it'll just shift the coverage to one side. The only exception may be the poles -- one pole will have better coverage than the other unless antenna direction is switched.

My favorite pet project in new scanners lies in satellites that require multiple vessels to provide any data (ala GRAIL or RBSP). In other words, scanning 3D volumes instead of surfaces. This, of course, is probably very difficult and all of the data would need to be implemented by us.

Those are pretty cool. Although, by the looks of it, RBSP is also finding data with respect to time, not just volume, which is why it's using multiple vessels.

Funny thing about GRAIL, it might actually be a replacement for the Gravioli detector. We don't have a sensor in real life that can directly measure gravity fields, only the acceleration caused by gravity fields. When I'd first heard about how GRAIL works, I thought it was pretty cool, too, but the math must be crazy.

Orbit projection doesn't work like I expected it to. I had those screenshots of me playing with it. What I found is that it was happy to project backwards, but would only project one orbit forwards.

This could have been the way I was doing it, though. *shrug*

Well, luckily that method only has to project backwards .

[Psawhn]

Sorry to double-post and keep spamming up your thread like this, but I just finished collating up the data.

To me, that is not only the obvious place to start to calibrate the FOVs and swath widths of scanners in RSS; it is also a good way to determine the realism level of scanners in the Kerbol system. I would be happy have someone to summarize the orbits used and the total scanning time needed and see how these scanners compare.

So I just looked up some satellites that I already knew by name, plus a few more I didn't know about, and collected their statistics. I tried to go for some with the widest swath widths, because resolution in the game isn't too high anyway.

While looking these up, I discovered that there's something called Interferometric SAR, which uses multiple passes to generate maps of surface deformation. Reading from the wikipedia link:

Interferograms can be used to produce digital elevation maps (DEMs) using the stereoscopic effect caused by slight differences in observation position between the two images. When using two images produced by the same sensor with a separation in time, it must be assumed other phase contributions (for example from deformation or atmospheric effects) are minimal. In 1995 the two ERS satellites flew in tandem with a one-day separation for this purpose. A second approach is to use two antennas mounted some distance apart on the same platform, and acquire the images at the same time, which ensures no atmospheric or deformation signals are present. This approach was followed by NASA's SRTM mission aboard the space shuttle in 2000. InSAR-derived DEMs can be used for later two-pass deformation studies, or for use in other geophysical applications.

It'd be funny if SAR required multiple passes in order to generate a DEM in the first place, but that'd probably be much too convoluted a process for most players. But you said that you were interested in tandem-vessel experiments, so I thought it'd be neat to bring it up.

[TABLE=width: 890]

[TR]

[TD]Satellite[/TD]

[TD]Link[/TD]

[TD]Inclination[/TD]

[TD]Altitude[/TD]

[TD]Period[/TD]

[TD] Swath Width[/TD]

[TD]Resolution[/TD]

[TD]Antenna[/TD]

[/TR]

[TR]

[TD=colspan: 2]Synthetic Aperture RADAR[/TD]

[TD][/TD]

[TD](km)[/TD]

[TD](mins)[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]ERS-2[/TD]

[TD]https://directory.eoportal.org/web/eoportal/satellite-missions/e/ers-2[/TD]

[TD]98.516

98.543

98.491[/TD]

[TD]785

782

770[/TD]

[TD]~100[/TD]

[TD]100 km[/TD]

[TD]30m[/TD]

[TD]325.8 kg[/TD]

[/TR]

[TR]

[TD]RADARSAT 1 and 2[/TD]

[TD]http://www.asc-csa.gc.ca/eng/satellites/radarsat/radarsat-tableau.asp http://en.wikipedia.org/wiki/Radarsat-2[/TD]

[TD=align: right]98.6[/TD]

[TD=align: right]798[/TD]

[TD=align: right]100.75[/TD]

[TD]500 km[/TD]

[TD]100 m[/TD]

[TD]750 kg,

15m x 1.5m[/TD]

[/TR]

[TR]

[TD]RADARSAT Constellation[/TD]

[TD][/TD]

[TD=align: right]97.74[/TD]

[TD=align: right]592.7[/TD]

[TD=align: right]96.4[/TD]

[TD]500 km[/TD]

[TD]100 m[/TD]

[TD]400kg,

6.75m x 1.38 m[/TD]

[/TR]

[TR]

[TD]ENVISAT[/TD]

[TD]https://earth.esa.int/web/guest/missions/esa-operational-eo-missions/envisat/instruments/asar http://en.wikipedia.org/wiki/Envisat[/TD]

[TD=align: right]98.4[/TD]

[TD=align: right]773[/TD]

[TD=align: right]100.16[/TD]

[TD]405 km[/TD]

[TD]150 m[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]TerraSAR-X[/TD]

[TD]https://directory.eoportal.org/web/eoportal/satellite-missions/t/terrasar-x[/TD]

[TD=align: right]97.44[/TD]

[TD=align: right]514.8[/TD]

[TD][/TD]

[TD]200 km[/TD]

[TD]35 m[/TD]

[TD]5m x 2.4m[/TD]

[/TR]

[TR]

[TD]Multispectral[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]LANDSAT 5/7/8[/TD]

[TD]http://geo.arc.nasa.gov/sge/landsat/l7.html http://landsat.usgs.gov/about_landsat5.php[/TD]

[TD=align: right]98.22[/TD]

[TD=align: right]705[/TD]

[TD=align: right]98.83[/TD]

[TD]185 km[/TD]

[TD]30 m[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]IRS-3[/TD]

[TD]https://directory.eoportal.org/web/eoportal/satellite-missions/i/irs-p3[/TD]

[TD=align: right]98.7[/TD]

[TD=align: right]817[/TD]

[TD=align: right]101.35[/TD]

[TD]770km /

200km[/TD]

[TD=colspan: 2]188 m /

520 m[/TD]

[/TR]

[TR]

[TD]kompsat-1[/TD]

[TD]https://directory.eoportal.org/web/eoportal/satellite-missions/k/kompsat-1[/TD]

[TD=align: right]98.13[/TD]

[TD=align: right]685[/TD]

[TD=align: right]98.46[/TD]

[TD]17 km / 800 km[/TD]

[TD]6.6m /

1 km[/TD]

[TD][/TD]

[/TR]

[/TABLE]

All of these satellites are in sun-synchronous orbits, which is why their inclinations are at about 98 degrees (retrograde). It's pretty important for EO satellites to take images at the same solar time of day each pass (typically about 9:30 AM to 10:00 AM). I think it might also allow them to remain in constant sunlight to keep the solar panels charged, having just enough altitude to reach sunlight while travelling over the night side at 10 PM. This cannot be replicated in KSP because orbits around non-spherical masses are not modelled.

[technogeeky]

Sorry to double-post and keep spamming up your thread like this, but I just finished collating up the data.

So I just looked up some satellites that I already knew by name, plus a few more I didn't know about, and collected their statistics. I tried to go for some with the widest swath widths, because resolution in the game isn't too high anyway.

While looking these up, I discovered that there's something called Interferometric SAR, which uses multiple passes to generate maps of surface deformation. Reading from the wikipedia link:

It'd be funny if SAR required multiple passes in order to generate a DEM in the first place, but that'd probably be much too convoluted a process for most players. But you said that you were interested in tandem-vessel experiments, so I thought it'd be neat to bring it up.

[TABLE=width: 890]

[TR]

[TD]Satellite[/TD]

[TD]Link[/TD]

[TD]Inclination[/TD]

[TD]Altitude[/TD]

[TD]Period[/TD]

[TD] Swath Width[/TD]

[TD]Resolution[/TD]

[TD]Antenna[/TD]

[/TR]

[TR]

[TD=colspan: 2]Synthetic Aperture RADAR[/TD]

[TD][/TD]

[TD](km)[/TD]

[TD](mins)[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]ERS-2[/TD]

[TD]https://directory.eoportal.org/web/eoportal/satellite-missions/e/ers-2[/TD]

[TD]98.516

98.543

98.491[/TD]

[TD]785

782

770[/TD]

[TD]~100[/TD]

[TD]100 km[/TD]

[TD]30m[/TD]

[TD]325.8 kg[/TD]

[/TR]

[TR]

[TD]RADARSAT 1 and 2[/TD]

[TD]http://www.asc-csa.gc.ca/eng/satellites/radarsat/radarsat-tableau.asp http://en.wikipedia.org/wiki/Radarsat-2[/TD]

[TD=align: right]98.6[/TD]

[TD=align: right]798[/TD]

[TD=align: right]100.75[/TD]

[TD]500 km[/TD]

[TD]100 m[/TD]

[TD]750 kg,

15m x 1.5m[/TD]

[/TR]

[TR]

[TD]RADARSAT Constellation[/TD]

[TD][/TD]

[TD=align: right]97.74[/TD]

[TD=align: right]592.7[/TD]

[TD=align: right]96.4[/TD]

[TD]500 km[/TD]

[TD]100 m[/TD]

[TD]400kg,

6.75m x 1.38 m[/TD]

[/TR]

[TR]

[TD]ENVISAT[/TD]

[TD]https://earth.esa.int/web/guest/missions/esa-operational-eo-missions/envisat/instruments/asar http://en.wikipedia.org/wiki/Envisat[/TD]

[TD=align: right]98.4[/TD]

[TD=align: right]773[/TD]

[TD=align: right]100.16[/TD]

[TD]405 km[/TD]

[TD]150 m[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]TerraSAR-X[/TD]

[TD]https://directory.eoportal.org/web/eoportal/satellite-missions/t/terrasar-x[/TD]

[TD=align: right]97.44[/TD]

[TD=align: right]514.8[/TD]

[TD][/TD]

[TD]200 km[/TD]

[TD]35 m[/TD]

[TD]5m x 2.4m[/TD]

[/TR]

[TR]

[TD]Multispectral[/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[TD][/TD]

[/TR]

[TR]

[TD]LANDSAT 5/7/8[/TD]

[TD]http://geo.arc.nasa.gov/sge/landsat/l7.html http://landsat.usgs.gov/about_landsat5.php[/TD]

[TD=align: right]98.22[/TD]

[TD=align: right]705[/TD]

[TD=align: right]98.83[/TD]

[TD]185 km[/TD]

[TD]30 m[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]IRS-3[/TD]

[TD]https://directory.eoportal.org/web/eoportal/satellite-missions/i/irs-p3[/TD]

[TD=align: right]98.7[/TD]

[TD=align: right]817[/TD]

[TD=align: right]101.35[/TD]

[TD]770km /

200km[/TD]

[TD=colspan: 2]188 m /

520 m[/TD]

[/TR]

[TR]

[TD]kompsat-1[/TD]

[TD]https://directory.eoportal.org/web/eoportal/satellite-missions/k/kompsat-1[/TD]

[TD=align: right]98.13[/TD]

[TD=align: right]685[/TD]

[TD=align: right]98.46[/TD]

[TD]17 km / 800 km[/TD]

[TD]6.6m /

1 km[/TD]

[TD][/TD]

[/TR]

[/TABLE]

All of these satellites are in sun-synchronous orbits, which is why their inclinations are at about 98 degrees (retrograde). It's pretty important for EO satellites to take images at the same solar time of day each pass (typically about 9:30 AM to 10:00 AM). I think it might also allow them to remain in constant sunlight to keep the solar panels charged, having just enough altitude to reach sunlight while travelling over the night side at 10 PM. This cannot be replicated in KSP because orbits around non-spherical masses are not modelled.

Nice post! This will prove helpful indeed.

I suppose we can just calculate it (and I also suppose it's somewhat arbitrary), but one thing I wanted to know was how long it took these satellites to complete a full map of the planet (indeed, if they ever did so).

That might require more digging or even e-mailing principal investigators

[phoenix_ca]

The existing colors for some maps are already (supposedly, I haven't verified yet) colorblind safe. However, some of the UI element colors are not. This is a known bug and will be fixed by v8, and will be tested in v7.

Unfortunately not true. The colour altitude map kinda falls apart. That website you linked is interesting, though I wouldn't trust it completely. The best way to test for colour-blindness support is to actually proof the colours with an example image. Photoshop has two proof modes for colour blindness, and there are piles of simulators that can do it.

Here's an online simulator you can use: http://www.color-blindness.com/coblis-color-blindness-simulator/

[Horus]

Totally marvelous idea to integrate scansat with resource mods (kethane)!

Thanks for your efforts!