Isis3: Set Reference Measure in CNETREF Based on Image ID

[astrostu]

Description
CNETREF is a great way to set the reference measure in a control net based on a lot of different criteria, but something I'm surprised it lacks is the ability to set it based on an image ID (either name or serial number, doesn't matter to me, but name would likely be more user-friendly).

Example
Something simple, like: cnetref from=myNet.noref.net to=myNet.withref.net criteria=IMAGENAME imagename=ThisIsMyImageName.cub

[jessemapel]

This is a good idea. How would you use this for large networks were each image only measures a small percentage of the points?

[astrostu]

Hmmm, good point. I suppose the simplest thing would be for the program to return a warning that some points were not changed, and to see an output log, since those points do not contain the image/measure in question.

A possible alternative or complementary method could be that the user supplies a priority list of what images will be the reference measure. Then, CNETREF would go through that list, for each point, and the first one on that list that is in that point would be set to the reference measure. Again, an automatic log (which could be turned off) would be generated to let the user know what was actually done, including if nothing was changed because a point had no measure in that list.

I think that might be the most straightforward way to handle things other than returning an automatic error?

The use case I'm looking at is that I've created a network specifically for a singular overlap region, so I know what images are there and they are all the same for my network (i.e., this network is specifically for a region on a body that is covered by images A, B, C, D, E, F, and G). I set the initial reference measure as the one with the lowest emission angle, run through POINTREG, and some measures for some points aren't registered. What I want to do then is to try the points that had unregistered measures and set the reference measure as one of those that didn't register, and try POINTREG again. Right now, I have to go through my own process of using Python to modify the network and write it out the way I want, which I can do (I'm doing it), but it just seems like this should be an "obvious" functionality of CNETREF, even though it could get complicated as you note when that measure isn't in the point.

[lwellerastro]

As @astrostu pointed out, this desired behavior would be best suited for small or regional networks, but could also apply to something global for lower resolution, flyby disk and limb data. It honestly doesn't matter in what context it would be used, it's a reasonable idea. I think the input would have to be filename or serial number since that is how images are referred to in networks.

cnetref typically doesn't not fail and quit when a reference can't be found, but I think it sets failed cases to "ignored" at the measure level, but I can't recall exactly. There is already and optional log file available to capture information, though this particular scenario might take some tweaking.

I set the initial reference measure as the one with the lowest emission angle, run through POINTREG, and some measures for some points aren't registered. What I want to do then is to try the points that had unregistered measures and set the reference measure as one of those that didn't register, and try POINTREG again.

I would really need to think about this for a bit, but I'm not sure this is the a good way to go though I understand why you would want to do this. Given this scenario, a point would have multiple references where x number of measures would be registered to reference A and x-number to newly selected reference B. A and B need to be registered to each other to have a stack of measures that completely registered to each other. But it seems in your case you can't A and B and their respective measures to register well, so you essentially have two distinct duplicate points that might end up with somewhat higher residuals. Or not because the offsets between A and B aren't that bad because spice is good and you get away with it. As larger scales automating this sort of behavior is not something I would encourage.

I have certainly done this sort of thing manually when fighting with difficult data where a single point in that location through those images is absolutely essential (Europa Galileo and Voyager data). Maybe 4 images register fairly well to the chosen or default reference but one image doesn't. I have been known to manually register the 5th image to one of the non-reference images to make things work, but it has always been done manually and with some thought. Unless the point is fixed or constrained, the reference doesn't matter (as far as jigsaw is concerned), but I think having the reference be a moving target is a tad dangerous.

I think at the most basic level having cnetref choose a reference based on a user supplied image name is fine and isn't any difference than other modes of choosing a reference, but I think implementing it in the way @astrostu would like to use it is better left to the user through scripting. But maybe I've completely blown it and don't quite understand the request.

[astrostu]

Sorry, let me try to clarify: The request is as I stated originally. The example use case is one I just had yesterday afternoon, and I tried to give the short-short-short version. I actually make a copy of the point, name it something unique, and change the reference measure for that new copy-with-unique-name.

As @lwellerastro said, there are plenty of scenarios where one might want CNETREF to set a reference based on an image name or SN (again, for user-ability I suggest name since almost no one knows the SN), my tortured case was just one very specific example of where I was fiddling with things to try to get as many measures registered for a point as I could (though of course there will be slight lat/lon/rad offsets in my method because the reference measure is different).

[lwellerastro]

@astrostu, I totally understand how there are no short ways to describe most things having to do with networks.

I was going to suggest the copy/rename of the point to avert the problem but I felt I was getting long-winded and opening up whole separate conversation. This is obviously part of what your python program is handling.

Honestly, it would be better if those measures could live in one point if possible. Jigsaw can adjust either of the new, seemingly identical points any which way it likes, possibly pulling them away from each other depending on other ties, etc. But I understand how you can find yourself here and opt to live with it. And I think with better data it's a non-problem in practice, though in theory it might make for a weaker network. At least that's what has shared with me by Ken Edmundson in the past.

And yes, filename as input is most desirable - serial numbers are the worst.

[astrostu]

@lwellerastro I sent you an email that gets more in-depth on what I do, I don't want to clog this thread. Short version: My code tries to do what you wrote.

[jessemapel]

@astrostu @lwellerastro Was there a resolution to the discussion of if this is a good idea?

[astrostu]

I think we agreed that it is a good idea. The discussion ended up being more about specific implementation of how I'm doing things in my workflow, not whether this, in principle, is a good nor bad idea.