Everyone, Before someone spends a lot of time re-working the ellipse code to add more splines, I think we should talk about the problem and maybe consider another approach.
The real problem w/ this for us is that we plot a lot of things at interplanetary scales (millions of kilometers). Even 1e-6 accuracy is still a miss of a kilometer (assuming that error tolerance is related to r). What we really need is something that is viewport (i.e. the data range being currently viewed) dependent. The errors for the 4 spline case are fine as long as it's a spline through 4 points that are in the viewport window. So if I have an ellipse that's 3 million by 5 million and I'm viewing the whole thing on a plot, 1e-4 of 3e6 is fine. However, if I've zoomed in to a portion of the ellipse and my current axes bounds are 10 km x 10 km, then 1e-4 isn't fine AND 1e-6 isn't fine either. If we could recompute the curve based on the current zoom level, then 1e-4 is fine again. One way to think about this is as error in pixels (since that's what the user is actually looking at). It would be nice if the pixel error could be held constant. Let's say that one pixel is the error we're going for. Any system that gives a one pixel error at arbitrary zoom levels is the way to go. A system with an error expressed in data coordinates will always have problems at some arbitrary zoom level. I don't know if the current MPL architecture can support this but it would be nice if it worked that way. We have people making decisions based on what these plots show that affect spacecraft worth hundreds of millions of dollars so it's important that we're plotting things accurately. Ted At 07:26 AM 12/10/2007, Michael Droettboom wrote: >John Hunter wrote: > > On Dec 10, 2007 8:51 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > > >> I have 8-spline approximation working on the trunk and on the transforms > >> branch. (r4679) > > > > Thanks Michael, I was working on this myself but it is hard for me to > > keep up with you :-) > >No problem. I wasn't sure if you were still on vacation... Feel free >to replace mine with whatever you came up with if you see further benefit. > > > In reading the paper Charlie sent and links therein > > (<http://www.tinaja.com/glib/ellipse4.pdf > and>http://www.tinaja.com/glib/ellipse4.pdf and > > http://itc.ktu.lt/itc354/Riskus354.pdf), one comment was that the > > usual magic number > > > > offset = 4.0 * (npy.sqrt(2) - 1) / 3.0 > > > > is not ideal. When I tested the JPLs test script with one of the > > suggested magic numbers which minimize the SS errors with 4 points on > > the ellipse, the error was smaller than what we were getting with the > > one above (I used k=0.55191496 from the Rivus paper). > >The first thing I tried when I saw Lancaster's paper (from Charlie's >e-mail) was to leave it as four splines and use his suggested number of >0.551784. That improved things for James' example, but not nearly >enough. There were still around 10 pixels between where the ellipses >should be and where they were. It's possible that an even better magic >number exists (I gather Lancaster's was arrived at by experimentation), >but I was doubtful that one could be found that would be as good as just >going to 8 splines. > > > I see you are > > using a different formula for the magic number in the trunk. Do you > > think we could see additional accuracy with a different magic number > > as discussed in these papers? > >For the 8 spline approximation I put in the trunk this morning, I used >Lancaster's suggested magic number of 0.2652031. (MAGIC45 is just the >rectilinear distance of the MAGIC number at a 45 degree angle). Again, >feel free to tinker, but that number seemed "good enough" on James' example. > >Cheers, >Mike > >-- >Michael Droettboom >Science Software Branch >Operations and Engineering Division >Space Telescope Science Institute >Operated by AURA for NASA > >------------------------------------------------------------------------- >SF.Net email is sponsored by: >Check out the new SourceForge.net Marketplace. >It's the best place to buy or sell services for >just about anything Open Source. >http://sourceforge.net/services/buy/index.php >_______________________________________________ >Matplotlib-devel mailing list >Matplotlib-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel Ted Drain Jet Propulsion Laboratory [EMAIL PROTECTED] ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
