Fixes to sgr coordinates example - #5210

(I milestoned it 1.3 because of the #5104 stuff, but the line style change we might just backport to 1.2.x as a single commit, as the example right now doesn't really make sense)

Ah, yes, I meant to do linestyle='none', marker='.' -- could you do that instead? Or, do:

.scatter(..., marker='.', color='k')

(I hate that default blue)

Ah, now I get the intent @adrn - thanks for clearing that up. Last push updated back to plot with marker='.'. Now it looks like this:

Note that the travis failure seems to be due to sesame being down

Huh, sounds like there's a @remote_data decorator missing? Or did we decide to include this one on Travis?

@astrofrog - it's from the example gallery, which doesn't obey @remote_data. (If it did it would fail with the "trying to access the internet" error). It's unrelated to this issue, though - it's a different example.

It does raise a question about that particular example though (the coordinates one) - that example doesn't work without remote data but we still want it to be generated in sphinx

@eteq @astrofrog - With a quick look it seems that there are two urls given for sesame, and the first one (cds) is indeed not responding, however the second one (cfa) seems to be working, which means there is a bug somewhere. I think it may worth an issue.

I think it's a separate issue to deal with the question of remote_data in the example gallery, right @astrofrog / @bsipocz ? It's definitely not directly related to the changes in this PR, as it's just using SkyCoord.from_name same as it did previously... And the error is currently happening in master anyway.

@mhvk - did you want to take a look at this or should I just go ahead and merge this?

@eteq - I now had a quick look, and am slightly wondering if we're being helpful here by writing it in such a way that it would still fail for multi-dimensional vectors or matrices.... Would it be possible to follow the built-in transformations more closely? In particular, use matrix_transpose (so multiple target systems could work -- not so useful here, really...), and xyz_new = coord_old.xyz.transform(matrix)

Closed by #5541