[APBeta] an obscure bug in importing?

[Paul Rodman]

On Sep 2, 2011, at 11:47 PM, Roberto Abraham wrote:

> I'm afraid I *may* have uncovered another obscure bug... 

Indeed you have...

> The file imports *nearly* successfully into AstroPlanner (as a Generic Text File, with Catalogue lookup based on ID) except a very curious thing happens. Only the objects in the Northern hemisphere are successfully matched to WDS objects in the AstroPlanner catalog. 

> As you can see in the screenshot all objects with negative declinations in their WDS ID's are not matched, while almost all WDS ID's with positive declinations are matched. (Parenthetically, I also note that the screenshot shows that the save button on the dialog box to save the format settings is grayed out... I think this might also be a bug).

This is a problem with the catalogue search code. You can also see it happen if you open the catalogue and use the find feature at the bottom.

> Anyway, sorry if this isn't a bug and I'm doing something silly here!

Definitely a bug. I'll look at it this weekend.

> P.S. You might find this amusing: While undertaking the marginal hack above it occurred to me that I could both avoid bugging you and also take this to the next geeky level by simply writing out the plan directly using python and not bothering with the AstroPlanner import step at all. Python has built-in sqlite support and it took five nanoseconds to figure out the required file format for a plan file. But of course you know how this is going to end... badly. It is indeed trivially easy to write out a plan which AstroPlanner will happily load, but of course the plan is useless since the base catalogs appear to be some sort of RealBasic data dump and not sqlite files, so I can't use python to embed CatIdx field needed by AstroPlanner in order to point to the objects in the WDS catalog. Foiled! So I conclude this is never going to work unless you someday decide to revise your catalog format for AstroPlanner 3. But in case you ever decide you want to write out a nearly-working A
> stroPlanner plan in python, here's a link so you can see how I did it. Note that this reads a simplified version of one of the Excel files above with the header stripped.

Don't worry about the CatIdx, it's only used if you (say) double-click a object and need to get back to the original entry in the catalogue. What you can do afterwards is use the Object > Refresh Objects from Catalogues feature which will update those fields (or would if the bug gets fixed :^)

Paul R.