You may have noticed an ephemeris option in Find_Orb, both in the on-line form version and in the compiled Windows or Linux software, for 'galactic confusion'. This option provides, at each ephemeris point, a number indicating the expected level of 'confusion' from galactic background stars. Get a value of zero, and your target will almost certainly not be lost in the background. Get a galactic confusion value of 100, and you're warned that finding a faint object in that mess will not be easy.
I added this because some people have used galactic latitude as a rough indicator of confusion : "if the target is within 10 degrees of the galactic equator, I'm not even going to try for it." The reality is more nuanced. There are 'holes' in the middle of Sagittarius, and places where there are plenty of background stars much more than ten degrees from the galactic equator. You can also lose things in globular clusters and the Magellanic Clouds. So the 'simple' approach can cause you to miss opportunities you should have taken, and to attempt observations when you'd have been better off observing somewhere else.
At present, the 'confusion' is pre-computed by counting the number of stars per unit area in the Gaia-DR catalogue. I wrote a bit of code to process the entire catalogue and count the stars brighter than mag 22 in each 0.1-degree square cell, for a 3600x1800 grid. I then scaled those counts to get a reasonably decent value from zero to 100. The above image is derived from that 3600x1800 grid (and was rendered in 'image' form, in part, so I could see what mistakes I might have made.)
This is already getting some good use, with observers finding that they can get targets they'd have given up on. However, it is something of an ad-hoc method.
After a bit of discussion, I've come to realize that ideally, this parameter would reflect the likelihood that background stars are going to interfere with your observation. If the GC parameter is 37, then there's a 37% probability that your observation will either fail or get bad data because of a background star or stars. (Note that the background star may just merge a bit with your target and cause you to get bad astrometry, which is usually worse than just not getting any astrometry at all.)
It'd be lovely if it worked that way, but there are some issues to be figured out before we can do that.
• Target brightness matters. A mag 12 target is going to be a lot harder to lose in the background than a mag 21 target.
• If the target is moving appreciably during the exposure, that can either make galactic confusion more of a problem, or less of one. If we're tracking sidereally, the target light will smear out and it'll be harder to find than a more "stationary" object. Track on the target, and it'll be easier to find it if it's moving a bit and the background stars are getting smeared.
• At present, I'm just counting stars in the 0.1-degree cell. A mag 18 star and a mag 21.5 star count equally. Ideally, we would know the number of stars in each half-mag bin. I think I can come up with a reasonably defensible formula to say, for example, "A mag 20.3 target must be at least X arcseconds from a mag 18.75 star to be properly observed." (Not that the formula will be simple. X would be smaller a larger telescope with good seeing and small pixels than for a small scope in bad skies with big pixels.) If there are N mag 18.5 to 19.0 stars in our (say) 0.1 by 0.1 degree cell, there will be πX²N square arcseconds where our target would be in trouble. Sum up those areas for each half-mag band, divide by the total area of 0.01 square degrees, and multiply by 100 to get your GC.
• Why, you may ask, 0.1 degree cells? It made a confusion map of manageable size. The one distributed with Find_Orb, in the file bright2.pgm, actually uses one-degree cells. We could probably have a finer-resolution cell size, but not by much; we'd start having few enough stars per cell to have random sampling issues.
Ideally, we'd have such maps at a variety of scales. If your ephemeris uncertainty is, say, 0.3 degrees, we'd look in the map with 0.1-degree cells and do a weighted average over the six or so cells in which the object might fall. If the uncertainty is low enough, we would actually query the Gaia-DR2 catalog and find out which individual stars are going to cause trouble. At that scale, the galactic confusion will change rapidly as the object moves. The drawback to this is that the version of Gaia-DR2 that I'm using, even with compression, tips the scales at about 45 GBytes. However, the code I'm using to extract star catalogue data for a given area is quite fast; speed/computational horsepower won't be an issue.