pmelchior / skymapper

Mapping astronomical survey data on the sky, handsomely
MIT License
43 stars 15 forks source link

Mouse position and interactions only partially functional #5

Closed pmelchior closed 8 years ago

pmelchior commented 8 years ago

For the aea projection, there's something odd happening with the cursor position. It works correctly west of ra_0, and continues to work past the last parallel on the west. So, this function also doesn't wrap correctly.

In addition, the mouse handlers for zoom and drag are probably not implemented or disabled.

rainwoodman commented 8 years ago

Indeed. The zoom and drag are disabled. I think in principle we have the information to enable them.

But doing patches is likely more important -- We'd like to use skymapper to make some nice foot-prints for DECALS DR2 targets completeness maps, and we will have to pixelize the data for visualization purposes.

pmelchior commented 8 years ago

Agreed, no urgency, but it's important to keep track of it.

As for DECALS: Why can't you use the implementation I created. It's not fully interactive because the tick labels and grid lines don't update correctly, but it does work.

rainwoodman commented 8 years ago

No it doesn't work neither, because DECALS spans almost 360 degrees in RA.

index

pmelchior commented 8 years ago

OK, please open a new issue about the patch breakup. This figure will be ideal to demonstrate the problem.

rainwoodman commented 8 years ago

Sure.

Other reasons for going native matplotlib:

  1. There will be 2 more people know what is going on with matplotlib's projection API. The total number could likely have doubled after we figure it all out, judged by the level of documentation and the number of projections in matplotlib.
  2. we can submit this as a patch -- especially if we can keep the historgram functionality without keeping the healpy dependency. Then(in a year or so) every computer will have aea projection installed by default. That would also urge people to look into adding angular histograms to geo mapping, then benefit another spectrum of the field --- Isn't that neat?

Yu

On Thu, Mar 17, 2016 at 3:10 PM, Peter Melchior notifications@github.com wrote:

OK, please open a new issue about the patch breakup. This figure will be ideal to demonstrate the problem.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/pmelchior/skymapper/issues/5#issuecomment-198083833

pmelchior commented 8 years ago

I agree, the native matplotlib version is the better way, but these are two independent problems:

  1. the polygon splitting
  2. problems with the native transformation

The first is true no matter if we use the projection class or the transformation class. I do want to have the transformation working (at least those transformation we care about).

rainwoodman commented 8 years ago

What you mean problems with the native transformation?

What about adding a project_path method to the class in skymapper like the one we have in aea_projection.py?

pmelchior commented 8 years ago

I meant problems with the mouse behavior in aea.

For now we could add a project_path method to skymapper, but it seems to me that you're pretty close to solving the entire problem with aea.

rainwoodman commented 8 years ago

What features are still missing in aea? I am not so familiar with these maps actually.

rainwoodman commented 8 years ago

Also the coordinate display seems to be because matplotlib is not even emitting the events. That's going to be some nasty internal details in matplotlib.