recent RMMercatorToScreenProjection:projectXY change has side effects in latLongToPixel

[GoogleCodeExporter]

This recent change to fix markers seems to have a side effect that shows in
latLongToPixel.

I had been using latLongToPixel to grab CGPoints of coordinates that are
off, or just-off, the visible screen.

With this new version, this sometimes works, but sometimes the off-screen
CGPoints alias back into the visible region.

Original issue reported on code.google.com by tracy.harton on 16 Apr 2009 at 7:03

[GoogleCodeExporter]

Could you post some (failing) numeric examples?

setZoom:xx
moveToPoint:yy

latLongToPixel:z1 -> ZZ1
latLongToPixel:z2 -> ZZ2 but should return ZZ3 instead

Original comment by halmuel...@gmail.com on 16 Apr 2009 at 11:24

[GoogleCodeExporter]

Good idea hal,

Here is a code snippet I threw in viewDidLoad():

    [[mapView contents] setZoom: 10];
    CLLocationCoordinate2D coord = {45.5,-121};
    [mapView moveToLatLong:coord];

    CGPoint point = [mapView latLongToPixel:coord];
    NSLog(@"%f %f", point.x, point.y);

    coord.longitude -= .125;
    point = [mapView latLongToPixel:coord];
    NSLog(@"%f %f", point.x, point.y);

    coord.longitude -= .125;
    point = [mapView latLongToPixel:coord];
    NSLog(@"%f %f", point.x, point.y);

Here are the different results:

r464:

2009-04-16 18:07:00.566 MapTestbed[76464:20b] 159.998459 230.000000
2009-04-16 18:07:00.567 MapTestbed[76464:20b] 68.976242 230.000000
2009-04-16 18:07:00.568 MapTestbed[76464:20b] 262121.968750 230.000000

r463:
2009-04-16 18:08:20.882 MapTestbed[76486:20b] 160.000000 230.000000
2009-04-16 18:08:20.883 MapTestbed[76486:20b] 68.977768 230.000000
2009-04-16 18:08:20.884 MapTestbed[76486:20b] -22.044455 230.000000

From my perspective, the negative CGPoint is correct, as that works well with
indexing in the layer for CG purposes.  

Original comment by tracy.harton on 17 Apr 2009 at 1:10

[GoogleCodeExporter]

Merged into issue 103.

I'll expand the unit tests to cover this case.

Fundamental problem is the discontinuity at +/- 180 degrees longitude. Pre 
r463, we just left the 
discontinuity alone, more or less? I don't remember for sure what the cutoff 
was for showing east longitude 
markers on left side of the screen vs west longitude markers on right side of 
screen.

r464 moves the discontinuity to the left hand edge of the screen. Having the 
discontinuity in the 
neighborhood of the screen is, for local search purposes, just as bad as having 
it actually on the screen.

A more standard approach is this: if +/- 180 is on (or near) screen, then add 
false easting of 360 to all west 
longitudes (negative longitudes). Thus, the longitude range shifts from (-180, 
+180) to (0, 360). The marker 
code is working in projected units (meters), so the delta is circumference of 
earth in meters. The test would 
need to be redone after every pan/zoom, but doesn't need a sqrt call for every 
point projected.

Basing marker position on projected units would become a problem if someone 
wanted to use a non-
rectangular projection (like a Robinson). It doesn't come into play yet in 
these samples.

Tracy: I believe that r463 would still fail if your initial moveToLatLong went 
to a longitude of, say, -179.8. 
That is, the third point's coordinates would come back with a large positive 
easting while the first two would 
show a  small positive easting, instead of the desired p3.x < p2.x < p1.x 
relationship.

Original comment by halmuel...@gmail.com on 17 Apr 2009 at 5:17

• Changed state: Duplicate