search

DOI-USGS / usgscsm

This repository stores USGS Community Sensor Model (CSM) camera models
Other
26 stars 33 forks source link

ProjectedSensorModel Question #477

Open jlaura opened 6 months ago

jlaura commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

@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.)