I did put a comment on the jira issue pointing to the code I wrote inside Chris Male perspective.
He answered on the JIRA topic as well.



2010/4/1 Grant Ingersoll <gsingers@apache.org>

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.


2010/3/31 Grant Ingersoll <gsingers@apache.org>
Anyone know what the point of this code is from the CartesianPolyFilterBuilder:

   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);


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)

To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org

Grant Ingersoll

Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search