Add seven new files for Multi-point capabilities. GAS/3.0.4 #24
Conversation
|
remove documents per NGA guidance |
| // polynomial and other non-physical models. The | ||
| // imageToProximateImagingLocus method should be used instead where | ||
| // possible. | ||
| //<````````````````````````````````````````````````````````1111111111111111111111111111111111111111111111111111111111111111111111111111 |
There was a problem hiding this comment.
Remove the spurious text in this comment line
|
|
||
| namespace csm | ||
| { | ||
| //***************************************************************************** |
There was a problem hiding this comment.
Please, no tab characters. Just use spaces to indent (though the other CSM code does not indent due to a namespace, so really no indent is needed here at all).
MultiPointRasterGM.h
Outdated
|
|
||
| namespace csm | ||
| { | ||
| class CSM_EXPORT_API MultiPointRasterGM : public RasterGM |
There was a problem hiding this comment.
I don't think that MultiPointRasterGM should derive from RasterGM. I think it should be its own interface that models could implement by deriving from both RasterGM and MultiPointRasterGM. That way it is optional, and clients can determine if it has this interface by doing something like MultiPointRasterGM* mpModel = dynamic_cast<MultiPointRasterGM*>(someRasterModel); if (mpModel) { ... }
Doing this allows for other classes like MPRGWrapper to only need to implement MultiPointRasterGM methods and not pass-throughs for all of the RasterGM methods.
There was a problem hiding this comment.
multiple designs were considered including this one.
MultiPointRasterGM.h
Outdated
| //< | ||
|
|
||
| virtual MultiEcefVector multiGetIlluminationDirection(const MultiEcefCoord& groundPts) const = 0; | ||
| virtual MultiDbl multiGetImageTime(const MultiImageCoord& imagePts) const = 0; |
There was a problem hiding this comment.
Are all these multi-point accessors really that useful? I suppose they probably aren't that hard to implement for plugins, but is there really a need to get the image times or illumination directions of lots of points in a single call? And will that really be that much faster than doing lots of calls? I'm worried about this interface becoming too complicated.
There was a problem hiding this comment.
these in particular were requested by JKarp.
| // Additions were made to the CSM API in CSM 3.0.2 to handle point clouds. | ||
| // The previous API did not change. Previously this code was in a separate | ||
| // library, but has now been migrated into a single library as of | ||
| // CSM3.0.3 |
There was a problem hiding this comment.
Probably need a better description here.
| // ----------- ------ ------- | ||
| // | ||
| // 22FEB2018 JPK Modified to use existing csm macros (since | ||
| // point cloud is no longer in a separate library). |
There was a problem hiding this comment.
Likely incorrect SW history
|
I don't think it's a good idea to add PDF files to this repository like that. Adding binary files just bloats the repository, making it slower to clone. Please remove them from this PR and do not do that in the future. |
|
I tried compiling these changes and got compile errors. Of course, that was after I updated the Also, I think you should do a |
|
Before this PR can be merged, the new files must be added to the |
No description provided.