bugfix for dataLim problem (Chris Barker)

Because collections have verts and offsets, which may have

    > separate transformations, it is not possible, in general, to
    > convert the plotted points to data units (which is what we
    > would need) until the viewLim is set; but that defeats the
    > purpose, which is to update the dataLim so that it can be
    > used to calculate viewLim.

Hey Eric, thanks for laying out the problem so clearly. The only way
for different transforms (eg the vert and offset transform) to
coordinate is to first convert to the common space (display/pixels)
and then invert back to their respective coordinates. And this isn't
possible if the viewlim aren't set, as you note. It's been a while
since I mucked around with the get_verts method in the collections
module, but I had the feeling that I had left it incomplete and your
post clarifies that.

    > The related bug is that the collection get_verts() methods
    > all simply add the offset to the verts and return the sums,
    > which are quite meaningless unless transform and transOffset
    > are identical; and even if they are identical, the units of
    > get_verts() will depend on the transform.

    > Options for adding some automatic dataLim updating option to
    > add_collection include:

    > 1) Don't even try. Simply require it to be done manually.
    > Make notes in docstrings and/or elsewhere.

    > 3) Do a partial job of it also in the case where transData

I think we can support auto-limits for collections reasonably
coherently. I'm inclined to leave the default behavior unchanged for
efficiency (no auto-limits) but to support a kwarg that does
auto-scaling

def add_collection(self, coll, autolim=False)

...or something to that effect.

If autolim is True, even given the problems you pointed out above, we
can support it in many common use cases.

There are two cases with no ambiguity that we could definitely support

* if no offsets are specified just use the verts

* if offsets are specified and the vert and offset transforms are
   the same it is straightforward to calculate the limits

If offsets are defined, one could, as Chris suggested, just use the
offsets to compute the limits. This would be "close enough" to get
most of the data into the axes, and the user could then tweak to their
heart's content. In this case we might want to warn.

JDH

John,

OK, I will put in a kwarg and support as many cases as reasonably possible. I was part-way there this weekend, but pulled back after running into the problem.

Eric

John Hunter wrote:

···

"Eric" == Eric Firing <efiring@...229...> writes:

    > Because collections have verts and offsets, which may have
    > separate transformations, it is not possible, in general, to
    > convert the plotted points to data units (which is what we
    > would need) until the viewLim is set; but that defeats the
    > purpose, which is to update the dataLim so that it can be
    > used to calculate viewLim.

Hey Eric, thanks for laying out the problem so clearly. The only way
for different transforms (eg the vert and offset transform) to
coordinate is to first convert to the common space (display/pixels)
and then invert back to their respective coordinates. And this isn't
possible if the viewlim aren't set, as you note. It's been a while
since I mucked around with the get_verts method in the collections
module, but I had the feeling that I had left it incomplete and your
post clarifies that.

    > The related bug is that the collection get_verts() methods
    > all simply add the offset to the verts and return the sums,
    > which are quite meaningless unless transform and transOffset
    > are identical; and even if they are identical, the units of
    > get_verts() will depend on the transform.

    > Options for adding some automatic dataLim updating option to
    > add_collection include:

    > 1) Don't even try. Simply require it to be done manually.
    > Make notes in docstrings and/or elsewhere.

    > 3) Do a partial job of it also in the case where transData

I think we can support auto-limits for collections reasonably
coherently. I'm inclined to leave the default behavior unchanged for
efficiency (no auto-limits) but to support a kwarg that does
auto-scaling

def add_collection(self, coll, autolim=False)

...or something to that effect.

If autolim is True, even given the problems you pointed out above, we
can support it in many common use cases.

There are two cases with no ambiguity that we could definitely support

* if no offsets are specified just use the verts

* if offsets are specified and the vert and offset transforms are
   the same it is straightforward to calculate the limits

If offsets are defined, one could, as Chris suggested, just use the
offsets to compute the limits. This would be "close enough" to get
most of the data into the axes, and the user could then tweak to their
heart's content. In this case we might want to warn.

JDH

John Hunter wrote:

def add_collection(self, coll, autolim=False)

...or something to that effect.

If offsets are defined, one could, as Chris suggested, just use the
offsets to compute the limits. This would be "close enough" to get
most of the data into the axes, and the user could then tweak to their
heart's content.

  it would give something useful to most users.My vote would be to make this the default, rather than nothing. It wouldn't be any more expensive than for the other plotting commands, and Having struggled with this, I know it would have taken me a while to find an autolim keyword, even if it had been there. Of course, It would have been a lot simpler if cla() had worked right, which Eric has fixed.

Perhaps I'm too focused on my use case, however. Any way you do it is quite usable.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...