realize_frame does not accept representation_type

I wanted to create a new frame using data coming from elsewhere, so realize_frame is exactly the method I needed. However, despite the name of its only parameter representation_type, the final representation_type of the result is the one coming from the default of the coordinate frame:

In [9]: ICRS().realize_frame(representation_type=CartesianRepresentation(1, 0, 0, unit='km'))
Out[9]: 
<ICRS Coordinate: (ra, dec, distance) in (deg, deg, km)
    (0., 0., 1.)>

In [10]: _.representation_type
Out[10]: astropy.coordinates.representation.SphericalRepresentation

In fact, BaseCoordinateFrame.realize_frame just calls _replicate, passing representation_type as data, which makes more sense, and _replicate does allow the user to override the default representation_type:

In [14]: ICRS()._replicate(data=CartesianRepresentation(1, 0, 0, unit='km'),
    ...: representation_type="cartesian")
Out[14]: 
<ICRS Coordinate: (x, y, z) in km
    (1., 0., 0.)>

I suggest that

• BaseCoordinateFrame.realize_frame parameter is renamed to data (which is less confusing),
• that it sets the representation_type using the class of the data,
• or alternatively that allows the user to override the representation_type in the proper sense:

In [2]: ICRS().realize_frame(data=CartesianRepresentation(1, 0, 0, unit='km'))
Out[2]: 
<ICRS Coordinate: (x, y, z) in km
    (1., 0., 0.)>

[mhvk]

My sense would be to just add **kwargs since that is what the “inverse”, replicate_without_data, does as well.

EDIT: the docstring could then explicitly mention that a possibly useful argument is representation_type

[eteq]

OK, to summarize a short discussion on slack: I think we agreed to switch to data for #7923 but leave for 3.2 the question of whether to add an additional argument or otherwise update the behavior.