Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ProjectedSensorModel Question #477

Open
jlaura opened this issue Feb 19, 2024 · 5 comments
Open

ProjectedSensorModel Question #477

jlaura opened this issue Feb 19, 2024 · 5 comments
Assignees

Comments

@jlaura
Copy link
Collaborator

jlaura commented Feb 19, 2024

How is the projected sensor model, either in usgscsm or perhaps in ALE, tracking what DTM was used in the creation of the projected image? Different DEMs will result in different ground locations which will then be projected to different map projected locations. So, the provenance tracking of the DEM is super important. Where is that tracked?

(I checked the CPP, but did not see anything in there. I also checked the ALE clipper drivers, but did not see anything in there.)

Thanks!

@thareUSGS
Copy link

Good question. I do think for this use-case (eclipper), intersecting a sphere (using the radius) is all that I think is currently called for. But for more general purpose, that capability could be useful.

@jlaura
Copy link
Collaborator Author

jlaura commented Feb 20, 2024

@thareUSGS Agree 90% for this specific use case. The chance of having an issue not zero though! It is lessened because only 2 (?) different spherical definitions are in general use. This is an issue we are working through with another data set right now since the IAU radii are not being universally used.

If the answer is, there is no tracking, then I would suggest that this is currently broken because of the implicit definition of the shape model / sphere. If it is tracked, awesome! My question is answered and we put this capability into general use.

@oleg-alexandrov
Copy link
Collaborator

In ASP every projected image keeps track of the input image, DEM, and bundle-adjust prefix. These are later read and validation checks happen. It is very useful to keep track of such things.

@acpaquette
Copy link
Collaborator

Agreed that we should likely keep track of it. When making the addition it wasn't something I had considered since, to my understanding, USGSCSM can't make use of the DEM directly

@jlaura
Copy link
Collaborator Author

jlaura commented Feb 20, 2024

@chkim-usgs This is a great candidate issue to slot for consideration for support. The sensor model implementation that knows about map projections is going to be gnarly / unusable in the general instance until this provenance tracking is included throughout the toolchain.

(P.S. We can hide this comment if this issue ends up getting considered for prioritization.)

@AustinSanders AustinSanders self-assigned this Mar 20, 2024
@Kelvinrr Kelvinrr self-assigned this Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

6 participants