kphotoalbum added a geolocation interface, with geoLat, geoLon, geoAlt (altitude) and geoPrec (precision, currently -1 anyway.) It was trivial to start picking these up and feeding them to flickr.photos.geo.setLocation calls after the uploads (just as with rotation, in async mode you have to wait for the photo ids to come back and then apply the changes.) Yay! Now I have end-to-end geotagging...
On top of that, I finally discovered what was wrong with flickr.photos.getWithGeoData - I was attempting to use page and per_page to work through smaller batches, and failing (the fields in the response were updated but the content wasn't.) Turns out that it simply doesn't work with XMLRPC - but passing the exact same arguments to the REST interface works just fine! Based on looking at the raw payloads I'm reasonably well convinced that it isn't my code or the python xmlrpclib itself... but flickr's API "community support" is a mix of unattended flickr groups and unusable yahoo lists, so now that I have a workaround (and a weak explanation/theory, namely, "nobody uses XMLRPC when there's REST available"), there isn't much more I can do. (It's too bad, as I've also caught a few spelling errors in the API docs that I'd be happy to see fixed...) So the next step is to use that interface and stuff older locations back into kphotoalbum; apparently flickr truncates to 6 digits, so kphotoalbum will remain the preferred source, but it will at least give me enough of a starting data set to start thinking about my own tools.