Rugged issueshttps://gitlab.orekit.org/orekit/rugged/-/issues2023-11-09T07:45:56Zhttps://gitlab.orekit.org/orekit/rugged/-/issues/395update to orekit 12.02023-11-09T07:45:56ZJonathan Guinetupdate to orekit 12.0https://gitlab.orekit.org/orekit/rugged/-/issues/394add PolynomialZHomothety in LOS transforms2023-03-24T08:04:17ZJonathan Guinetadd PolynomialZHomothety in LOS transformshttps://gitlab.orekit.org/orekit/rugged/-/issues/389add a tileupdater implements about Noaa's GLOBE DEM2021-12-11T12:47:20Zyoungcleadd a tileupdater implements about Noaa's GLOBE DEM
add a tileupdater implements about Noaa's GLOBE DEM which is descript in the doc [globedocumentationmanual.pdf](/uploads/2c7a21aeed9d243952ba5a0a4f973064/globedocumentationmanual.pdf)
in a rugged discussion in the forum, master Luc adv...
add a tileupdater implements about Noaa's GLOBE DEM which is descript in the doc [globedocumentationmanual.pdf](/uploads/2c7a21aeed9d243952ba5a0a4f973064/globedocumentationmanual.pdf)
in a rugged discussion in the forum, master Luc advice me to contribute my codes,i would love to have a try.
i have make a fork and i will try to contribute my implements code to rugged.https://gitlab.orekit.org/orekit/rugged/-/issues/242InverseLocation: maybe inappropriate use of coarse threshold in SensorPixelCr...2018-08-07T14:16:21ZGuylaine PratInverseLocation: maybe inappropriate use of coarse threshold in SensorPixelCrossingIn Rugged.inverseLocation method, in the first step to find the mean
plane crossing (method getPlaneCrossing),
the accuracy is set to COARSE\_INVERSE\_LOCATION\_ACCURACY (= 0.01).
In the second step, to find approximately the pixel al...In Rugged.inverseLocation method, in the first step to find the mean
plane crossing (method getPlaneCrossing),
the accuracy is set to COARSE\_INVERSE\_LOCATION\_ACCURACY (= 0.01).
In the second step, to find approximately the pixel along the sensor
line, the same accuracy is used.
It may not be sufficient, as for an expected inverse location of (0, 0),
according to the (min, max) lines given,
the SensorPixel found is
- (Line: -2.53e-3, pixel: -7.6e-7) for (minLine = -12046; maxLine
= 10993)
- (Line: -2.79e-7, pixel: -7.6E-7) for (minLine = -29277; maxLine
= 69120)
*(from redmine: issue id 242, created on 2016-05-24)*https://gitlab.orekit.org/orekit/rugged/-/issues/186Allow user customization of terrain masking influence in inverse location2018-08-07T14:16:07ZLuc MaisonobeAllow user customization of terrain masking influence in inverse locationInverse location currently ignores terrain masking effect. When the user
specifies
a ground location that in fact would be being some other ground feature
as seen from the
spacecraft (and therefore should not be visible in direct loc...Inverse location currently ignores terrain masking effect. When the user
specifies
a ground location that in fact would be being some other ground feature
as seen from the
spacecraft (and therefore should not be visible in direct location), the
computation is
done ignoring this effect. This implies that two different ground points
could theoretically
be mapped to the exact same sensor pixel in inverse location, whereas
this pixel location would
be mapped to only one of these ground points in direct location.
The current process is perfectly sound in some image processing chains
when the masking effects
are considered later on in the processing. However, in some cases it
would be interesting for user
to be able to select a different behavior and be warned that the
specified ground point cannot be
seen during this spacecraft pass over the area. There are two
possibilities for this: either an exception
should be thrown or simply a null result could be returned. The second
possibility (null return) seems
more logical for this case, as it is simply equivalent to a "No DATA"
information, its not a logical
error as would be implied by an exception.
*(from redmine: issue id 186, created on 2015-01-13)*