search

icecube / NuCat

https://nucat.icecube.aq/app
0 stars 2 forks source link

Support for non-circular uncertainty regions #8

Closed ChujieChen closed 3 years ago

ChujieChen commented 3 years ago

We need some events to test this functionality.

ChujieChen commented 3 years ago

It seems a harder problem than I thought. The skymap on a detail page would draw the contour50 or contour90 using candidate.json.contour50 and condidate.json.contour90. However, there is no candidate.json in the Candidate schema. And thus, there are 3 solutions:

Solution 1: Don't change the schema of candidate (meaning not to store json in a candidate), but read each info from candidate.infos then get info.json.contour50. We would still get one skymap on each detail page.

Solution 2: Still change nothing, but plot one skymap for each individual detail card. We would have multiple skymaps on each detail page. Nah, that would be ugly.

Solution 3: Change the schema of candidate (meaning to store json in the candidate). That means we need changes in candidate-model.js and info-ctrl.js to make sure if an info contains json, we append the info.json to the parent candidate.json. Note that we need to make this candidate.json optional since not all candidates have things like contour50.

mbbu3 commented 3 years ago

I think solution 1 would be the simpler answer but solution 3 would be more intuitive based on the candidate-info model we have set up. If we go with solution 3 that would also mean we would have to go back and change previously made candidates, which I'm not sure how much of a hassle that would be. But I think in the long-term solution 3 would be the better solution

ChujieChen commented 3 years ago

I think solution 1 would be the simpler answer but solution 3 would be more intuitive based on the candidate-info model we have set up. If we go with solution 3 that would also mean we would have to go back and change previously made candidates, which I'm not sure how much of a hassle that would be. But I think in the long-term solution 3 would be the better solution

I agree with you. I think solution 3 is the right way to go. We don't need to go back and change the formats of previously made candidates though, thanks to the flexibility of MongoDB.