Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
R
Rugged
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 4
    • Issues 4
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Orekit
  • Rugged
  • Issues
  • #186

Closed
Open
Opened Jan 13, 2015 by Luc Maisonobe@lucOwner

Allow user customization of terrain masking influence in inverse location

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)

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: orekit/rugged#186