The problem: There is a bulk offset that can range from small to ~22' (largest observed so far) in the combined maps that is not present in the individual maps. Observations: I THINK the offset between ra/dec and l/b is most pronounced when the map boundaries are most different. We have been putting CRPIX in the middle of the map (i.e. number of x/y elements divided by 2), which is not the same position as the median ra/dec or l/b. I figured this might be a problem, but there's not really a way around it - if you just set CRPIX to be 0,0, it doesn't change anything. xy2ad and ad2xy produce self-consistent results, but that doesn't mean anything either. I think the problem is that AD2XY is largely ignorant of CRPIX: it calculates x/y offsets from the CRVAL assuming that the CRVAL is at CRPIX.... but I don't know why that should be wrong. Ideas? More to come if I figure anything out. Update: from doing the individual maps in l/b vs ra/dec, I don't think the offset is between l/b and ra/dec.... something less fundamental. Update 2: still no clues after reading ad2xy and trying to plow through parts of wcssph2xy. gotta be rect_pix_tstream, but I think it's right.... Update 3: I think I have figured out the problem, currently testing. My idea has to do with the fact that all x,y positions in rect_pix_tstream are positive, but ad2xy is not constrained to return positive values. In principle, the two-iteration ad2xy should take care of this, but in the case where the middle of the map in pixels is not the middle of the map in the WCS coordinate system, it is still possible to get negative pixel mappings out of the 2nd iteration. I'm still confused about whether this is really possible - makes my head fuzzy - but I tried implementing a solution where I simply shift the crpix rather than recalculating with AD2XY. Update 4: Based on L111, my test in update 3 fixed the problem. Scuba contours are correct, and reasonably consistent across the field - still need to do the more complete test, e.g. Cygnus Update 5: Cygnus tests still await completion, but a very close inspection of single L111 maps reveals a ~2 pixel difference that could go a long way to explaining my high-RMS pointing calculations. Still doesn't explain the sine curve, but anything helps... Update 6: My correction definitely fixed the problem, EXCEPT there's still an ambiguity at the .5 pixel level. Specifically, is AD2XY treating the pixel center as .5,.5 or 0,0? Ditto IDL. I believe (from my simulated data) that this ambiguity is still causing a problem. Update 7: New correction fixed problem to better than 1" (checked by making a simulated map with 1" pixels) - probably 'perfect' now. Read prepare_map.pro for details. The issue was a difference in pixel centers.