Hi Bill,
you are right about it might be undoable to at runtime. 13 years ago I had a similar problem were I had to match objects which where chosen from a neural network and considered as galaxies to be cluster members. If one takes away the meaning of this tasks and reduces it to what it is in a computer scientist's way, that it is just matching objects in two list where every list entry has certain errors. If theses list have huge amounts of data and let's say just a few points which could be used for matching like coordinates than this task requires techniques like multithreading on multiple cores, segmentation of the lists to be split up to multiple cores and neural nets which speed up the matching process.
I had some major success with a method call friends-to-friends analysis which I put into a neural net. Sure one has to narrow down typical off-set of potential "friends" which fails for tight star clusters or deep imagery because of the poor deblending. For catalogs there is the same problem as you mentioned it because of the difference in accuracy which is based on the resolution of the underlying image sources.
But one can do something to improve chance of having matched catalogs.
First, for many of the well know objects these matchings are done like Messier is matched to NGC and in both available cats one finds their other names. This is carried on for the guide star catalog, too for example but it's incomplete due to lacking resources thoses days. In a short percentage Tycho2 for example has proper matches for some bright and well know objects already but for everything faint beyond amateur observation's there is non because this isn't important for pro's. Every researcher has his own catalogs in addition, too.
Additionally, catalogs like UCAC4 or USNOB2 which consumes 80gig and is available only on HDD for very few people, there are to many objects which have been recorded for the first time and are unmatchable.
Taking into account that cpu's nowadays might be more cable of doing such a crossmatching job, it would have to be a no-runtime job because of it's still hard number crunching even for up to 4Ghz-quatcore and more.
I helped myself by defining the magnitutes when to display what object. If this is well done, and defining that takes some time, multiple representations don't occur very often or I want them to happen. Since UCAC4 doesn't has much more information about what other names an object has or what additional information there is on it's movement, it's redshift, it's mass, colour, type etc, one would consult other catalogs to get this information. Showing multiple representations makes these other infos accessible. One would loose this option until one merges every bit of information from different catalogs which would be much more effort than just reducing the multiple displays.
Many additional information like observational descriptions, which are subjective as a personal impression, came from amateurs. They are not available from fainter objects and in this matter not mergeable.
So summing all that up for an idea to deal with it:
- One could set up some kind of friends-to-friends analysis, but it's slow and not free of mistakes due to the mistakes in the catalogs and their resolution.
- One can set up a very fine tuned display policy for when which catalog is used for display.
- Leaving it as it is because there are just too few people who might need it.
For me the second way works fine, because I have my experiences to know how unpleasant and unnecessary the matching process is.
clear skies,
Christian
--
"A little learning never caused anyone's head to explode!"
"Ein wenig Lernen hat noch niemandens Kopf zum Explodieren gebracht!"
>________________________________
> From: Bill Gray <pluto@...>
>To: guide-user@yahoogroups.com
>Sent: Monday, June 17, 2013 6:40 PM
>Subject: Re: [guide-user] Representations duplicate guide9.0 star
>
>
>
>
>
>
>On 06/11/2013 12:51 PM, pastorgalactico wrote:
>> Hello;
>>
>> Why in guide 9.0 to represent a star out up to 3 representations of the same star at nearby positions, for example;
>>
>> Polaris
>> Out 4UC897-000295 RA: 2h31m52. +89 15 '50,632 "
>>
>> Polar TYC 4628 237 1 02 31 47.08 +89 15 50.9
>>
>> 02h31m47.0780s A2_1725_00116912 +89 15 '50,890 "
>>
>> This happens if we have to leave the catalog represented ucac4 and USNOA2 and high zoom.
>> Is there any way to solve this.?
>
>Not at present, no.
>
>This is a problem of (_very_) long standing. I was able to address it with Guide's
>"built-in" catalogs by doing a lot of pre-processing to flag which stars appeared in
>other catalogs. I don't have such a system for added catalogs such as UCAC-4 and A2.0.
>
>I don't think it's impossible to do this. Essentially, Guide would need to be
>able to say: "First, draw Tycho-2 stars. Next, when drawing each UCAC-4 star,
>check to see if is within (say) .5 arcseconds of a Tycho-2 star that has already
>been drawn. If so, don't draw it. Next, draw the A2.0 stars; when doing so,
>check to see if the star is within (say) two arcseconds of a UCAC or Tycho-2 star."
>
>The tolerances would have to be flexible, and would vary from one dataset to the
>next. A2.0 is nowhere near as exact as UCAC-4; if the positions are two arcseconds
>apart, it's probably still a duplicate object. But a 2" separation between Tycho-2
>and UCAC-4 may be "real".
>
>A smarter algorithm would probably notice if multiple stars were within the
>distance of a previously-catalogued star. Suppose you've got a mag 10.5 Tycho-2
>star, and UCAC-4 shows a mag 10.5 star within 0.1" and a mag 12.3 star 1.2"
>away. In this case, I'd bet that UCAC-4 has successfully split a close double
>that Tycho-2 missed.
>
>I long considered this to be a nice idea, but unfeasible because of the
>processing power required. (Which is why I basically did the same thing for
>Guide's built-in datasets, but did it ahead of time, processing the data over
>a few nights.) I have to admit that, with current processors, it might be
>becoming feasible to do this in real time.
>
>The current method _does_ mean that you can get information from each of the
>catalogs. But of course, that just means it should be possible to shut off the
>scheme I've just described (perhaps by temporarily setting all of those distances
>to zero arcseconds.)
>
>-- Bill
>
>
>
>
[Non-text portions of this message have been removed]