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.

Regards,

Nicolas

2010/4/1 Grant Ingersoll

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
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-unsubscribe@lucene.apache.org