On Mar 31, 2010, at 6:08 PM, Helleringer, Nicolas wrote: > I do. > > It is clearly related to prime meridian handling but it is unreadable and > buggy.
Yeah, I put up and committed a bunch of comments. > > I did a complete rewrite of this sector of code commited to Chris Male > repository (working together to rework the whole thing). I put up a patch on https://issues.apache.org/jira/browse/LUCENE-2359. How does your's compare? Can you post it? > > Commit of this work should be done by Chris very soon. > > Hope it will help. > > Nicolas > > 2010/3/31 Grant Ingersoll <gsing...@apache.org> > Anyone know what the point of this code is from the > CartesianPolyFilterBuilder: > > <code> > shape = getShapeLoop(shape, ctp, latX, longX, latY, longY); > if (longX2 != 0.0) { > if (longX2 != 0.0) { > if (longX == 0.0) { > longX = longX2; > longY = 0.0; > shape = getShapeLoop(shape, ctp, latX, longX, latY, longY); > } else { > longX = longX2; > longY = -180.0; > shape = getShapeLoop(shape, ctp, latY, longY, latX, longX); > } > } > > </code> > > Why the double check on longX2? I think it's trying to get at edge cases > (based on earlier statements to do with prime meridian and the 180 longitude. > > Also, I see the following comment: > double startY = beginAt - startX ; //should give a whole number > > Yet, in debugging, I don't see how it is ever a whole number, b/c, AIUI, the > left side of the decimal of a box number is the X value (latitude) and the > right side of the decimal is the Y value. > > FWIW, I'm testing how all this tile stuff behaves across the 180th degree > longitude (and it doesn't seem to be behaving well) > > -Grant > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -------------------------- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search
