Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>As this area is woefully under-documented, the <a href="http://developer.apple.com/library/IOs/#documentation/MapKit/Reference/MapKitFunctionsReference/Reference/reference.html" rel="nofollow noreferrer">Map Kit Functions Reference</a> should be amended with:</p> <blockquote> <p><strong>Warning:</strong> All the described functions work fine, as long as you do not cross the 180th meridian.<br> <a href="http://en.wikipedia.org/wiki/Here_be_dragons" rel="nofollow noreferrer"><strong><em>Here be dragons</em></strong></a>. You have been warned...</p> </blockquote> <p>To solve this question, I have resorted to the good old investigative testing. Please excuse the comments around the prose. They allow you to <strong>copy &amp; paste</strong> <em>all source below verbatim</em>, so that you can play with it yourself. </p> <p>First a little helper function that converts the corner points of <code>MKMapRect</code> back into coordinate space, so that we can compare results of our conversions with the starting coordinates:</p> <pre><code>NSString* MyStringCoordsFromMapRect(MKMapRect rect) { MKMapPoint pNE = rect.origin, pSW = rect.origin; pNE.x += rect.size.width; pSW.y += rect.size.height; CLLocationCoordinate2D sw, ne; sw = MKCoordinateForMapPoint(pSW); ne = MKCoordinateForMapPoint(pNE); return [NSString stringWithFormat:@"{{%f, %f}, {%f, %f}}", sw.latitude, sw.longitude, ne.latitude, ne.longitude]; } </code></pre> <p>/*<br> And now, let's test </p> <h2>How To Create MapRect Spanning 180th Meridian:</h2> <p>*/ </p> <pre><code>- (void)testHowToCreateMapRectSpanning180thMeridian { </code></pre> <p>/*<br> We'll use <a href="http://maps.googleapis.com/maps/api/geocode/xml?address=Asia&amp;sensor=false" rel="nofollow noreferrer">location viewport of <strong>Asia</strong></a>, as returned by Google Geocoding API, because it spans the <a href="http://en.wikipedia.org/wiki/Antimeridian" rel="nofollow noreferrer">antimeridian</a>. The <strong>northeast</strong> corner lies already in western hemisphere—longitudal range <code>(-180,0)</code>:<br> */</p> <pre><code>CLLocationCoordinate2D sw, ne, nw, se; sw = CLLocationCoordinate2DMake(-12.9403000, 25.0159000); ne = CLLocationCoordinate2DMake(81.6691780, -168.3545000); nw = CLLocationCoordinate2DMake(ne.latitude, sw.longitude); se = CLLocationCoordinate2DMake(sw.latitude, ne.longitude); </code></pre> <p>/*<br> For the reference, here are the bounds of the whole projected world, some <strong>268 million</strong>, after converting to <code>MKMapPoints</code>. Our little helper function shows us that the Mercator projection used here is unable to express latitudes above ±85 degrees. Longitude spans nicely from -180 to 180 degrees.<br> */</p> <pre><code>NSLog(@"\nMKMapRectWorld: %@\n =&gt; %@", MKStringFromMapRect(MKMapRectWorld), MyStringCoordsFromMapRect(MKMapRectWorld)); // MKMapRectWorld: {{0.0, 0.0}, {268435456.0, 268435456.0}} // =&gt; {{-85.051129, -180.000000}, {85.051129, 180.000000}} </code></pre> <p>/*<br> Why was the <code>MKPolygon</code> overlay, created using the geo-coordinates, displayed in the wrong place on the map?<br> */</p> <pre><code>// MKPolygon bounds CLLocationCoordinate2D coords[] = {nw, ne, se, sw}; MKPolygon *p = [MKPolygon polygonWithCoordinates:coords count:4]; MKMapRect rp = p.boundingMapRect; STAssertFalse(MKMapRectSpans180thMeridian(rp), nil); // Incorrect!!! NSLog(@"\n rp: %@\n =&gt; %@", MKStringFromMapRect(rp), MyStringCoordsFromMapRect(rp)); // rp: {{8683514.2, 22298949.6}, {144187420.8, 121650857.5}} // =&gt; {{-12.940300, -168.354500}, {81.669178, 25.015900}} </code></pre> <p>/*<br> It looks like the longitudes got swapped the wrong way. Asia is <code>{{-12, 25}, {81, -168}}</code>. The resulting <code>MKMapRect</code> does not pass the test using the <code>MKMapRectSpans180thMeridian</code> function —and we know it should! </p> <h2>False Attempts</h2> <p>So the <code>MKPolygon</code> does not compute the <code>MKMapRect</code> correctly, when the coordinates span the antimeridian. OK, let's create the map rect ourselves. Here are two methods suggested in answers to <a href="https://stackoverflow.com/questions/8496551/">How to fit a certain bounds consisting of NE and SW coordinates into the visible map view?</a></p> <blockquote> <p>... quick way is a slight trick using the MKMapRectUnion function. Create a zero-size MKMapRect from each coordinate and then merge the two rects into one big rect using the function: </p> </blockquote> <p>*/</p> <pre><code>// https://stackoverflow.com/a/8496988/41307 MKMapPoint pNE = MKMapPointForCoordinate(ne); MKMapPoint pSW = MKMapPointForCoordinate(sw); MKMapRect ru = MKMapRectUnion(MKMapRectMake(pNE.x, pNE.y, 0, 0), MKMapRectMake(pSW.x, pSW.y, 0, 0)); STAssertFalse(MKMapRectSpans180thMeridian(ru), nil); // Incorrect!!! STAssertEquals(ru, rp, nil); NSLog(@"\n ru: %@\n =&gt; %@", MKStringFromMapRect(ru), MyStringCoordsFromMapRect(ru)); // ru: {{8683514.2, 22298949.6}, {144187420.8, 121650857.5}} // =&gt; {{-12.940300, -168.354500}, {81.669178, 25.015900}} </code></pre> <p>/*<br> Curiously, we have the same result as before. It makes sense that <code>MKPolygon</code> should probably compute its bounds using <code>MKRectUnion</code>, anyway.</p> <p>Now I've done the next one myself, too. Compute the MapRect's origin, width and hight manually, while trying to be fancy and not worry about the correct ordering of the corners.<br> */</p> <pre><code>// https://stackoverflow.com/a/8500002/41307 MKMapRect ra = MKMapRectMake(MIN(pNE.x, pSW.x), MIN(pNE.y, pSW.y), ABS(pNE.x - pSW.x), ABS(pNE.y - pSW.y)); STAssertFalse(MKMapRectSpans180thMeridian(ru), nil); // Incorrect!!! STAssertEquals(ra, ru, nil); NSLog(@"\n ra: %@\n =&gt; %@", MKStringFromMapRect(ra), MyStringCoordsFromMapRect(ra)); // ra: {{8683514.2, 22298949.6}, {144187420.8, 121650857.5}} // =&gt; {{-12.940300, -168.354500}, {81.669178, 25.015900}} </code></pre> <p>/*<br> Hey! It is the same result as before. This is how the latitudes get swapped, when the coordinates cross the antimeridian. And it is probably how the <code>MKMapRectUnion</code> works, too. Not good...<br> */</p> <pre><code>// Let's put the coordinates manually in proper slots MKMapRect rb = MKMapRectMake(pSW.x, pNE.y, (pNE.x - pSW.x), (pSW.y - pNE.y)); STAssertFalse(MKMapRectSpans180thMeridian(rb), nil); // Incorrect!!! Still :-( NSLog(@"\n rb: %@\n =&gt; %@", MKStringFromMapRect(rb), MyStringCoordsFromMapRect(rb)); // rb: {{152870935.0, 22298949.6}, {-144187420.8, 121650857.5}} // =&gt; {{-12.940300, 25.015900}, {81.669178, -168.354500}} </code></pre> <p>/*<br> Remember, the Asia is <code>{{-12, 25}, {81, -168}}</code>. We are getting back the right coordinates, but the <code>MKMapRect</code> does not span the antimeridian according to <code>MKMapRectSpans180thMeridian</code>. What the...?!</p> <h2>The Solution</h2> <p>The hint from <code>MKOverlay.h</code> said:</p> <blockquote> <p>For overlays that span the 180th meridian, boundingMapRect should have either a negative MinX or a MaxX that is greater than MKMapSizeWorld.width.</p> </blockquote> <p>None of those conditions is met. What's worse, the <code>rb.size.width</code> is <strong>negative</strong> 144 million. That's definitely wrong.</p> <p>We have to correct the rect values when we pass the antimeridian, so that one of those conditions is met:<br> */</p> <pre><code>// Let's correct for crossing 180th meridian double antimeridianOveflow = (ne.longitude &gt; sw.longitude) ? 0 : MKMapSizeWorld.width; MKMapRect rc = MKMapRectMake(pSW.x, pNE.y, (pNE.x - pSW.x) + antimeridianOveflow, (pSW.y - pNE.y)); STAssertTrue(MKMapRectSpans180thMeridian(rc), nil); // YES. FINALLY! NSLog(@"\n rc: %@\n =&gt; %@", MKStringFromMapRect(rc), MyStringCoordsFromMapRect(rc)); // rc: {{152870935.0, 22298949.6}, {124248035.2, 121650857.5}} // =&gt; {{-12.940300, 25.015900}, {81.669178, 191.645500}} </code></pre> <p>/*<br> Finally we have satisfied the <code>MKMapRectSpans180thMeridian</code>. Map rect width is positive. What about the coordinates? Northeast has longitude of <code>191.6455</code>. Wrapped around the globe (-360), it is <code>-168.3545</code>. <strong>Q.E.D.</strong></p> <p>We have computed the correct <code>MKMapRect</code> that spans the 180th meridian by satisfying the second condition: the <strong>MaxX</strong> (<code>rc.origin.x + rc.size.width</code> = 152870935.0 + 124248035.2 = 277118970.2) is greater then width of the world (268 million).</p> <p>What about satisfying the first condition, negative MinX === <code>origin.x</code>?<br> */</p> <pre><code>// Let's correct for crossing 180th meridian another way MKMapRect rd = MKMapRectMake(pSW.x - antimeridianOveflow, pNE.y, (pNE.x - pSW.x) + antimeridianOveflow, (pSW.y - pNE.y)); STAssertTrue(MKMapRectSpans180thMeridian(rd), nil); // YES. AGAIN! NSLog(@"\n rd: %@\n =&gt; %@", MKStringFromMapRect(rd), MyStringCoordsFromMapRect(rd)); // rd: {{-115564521.0, 22298949.6}, {124248035.2, 121650857.5}} // =&gt; {{-12.940300, -334.984100}, {81.669178, -168.354500}} STAssertFalse(MKMapRectEqualToRect(rc, rd), nil); </code></pre> <p>/*<br> This also passes the <code>MKMapRectSpans180thMeridian</code> test. And the reverse conversion to geo-coordinates gives us match, except for the southwest longitude: <code>-334.9841</code>. But wrapped around the world (+360), it is <code>25.0159</code>. <strong>Q.E.D.</strong></p> <p>So there are two correct forms to compute the MKMapRect that spans 180th meridian. One with <strong>positive</strong> and one with <strong>negative origin</strong>.</p> <h2>Alternative Method</h2> <p>The negative origin method demonstrated above (<code>rd</code>) corresponds to the result obtained by alternative method suggested by <a href="https://stackoverflow.com/users/467105/anna-karenina">Anna Karenina</a> in another answer to this question:<br> */</p> <pre><code>// https://stackoverflow.com/a/9023921/41307 MKMapPoint points[4]; if (nw.longitude &gt; ne.longitude) { points[0] = MKMapPointForCoordinate( CLLocationCoordinate2DMake(nw.latitude, -nw.longitude)); points[0].x = - points[0].x; } else points[0] = MKMapPointForCoordinate(nw); points[1] = MKMapPointForCoordinate(ne); points[2] = MKMapPointForCoordinate(se); points[3] = MKMapPointForCoordinate(sw); points[3].x = points[0].x; MKPolygon *p2 = [MKPolygon polygonWithPoints:points count:4]; MKMapRect rp2 = p2.boundingMapRect; STAssertTrue(MKMapRectSpans180thMeridian(rp2), nil); // Also GOOD! NSLog(@"\n rp2: %@\n =&gt; %@", MKStringFromMapRect(rp2), MyStringCoordsFromMapRect(rp2)); // rp2: {{-115564521.0, 22298949.6}, {124248035.2, 121650857.5}} // =&gt; {{-12.940300, -334.984100}, {81.669178, -168.354500}} </code></pre> <p>/*<br> So if we manually convert to <code>MKMapPoint</code>s and fudge the negative origin, even the <code>MKPolygon</code> can compute the <code>boundingMapRect</code> correctly. Resulting map rect is equivalent to the nagative origin method above (<code>rd</code>).<br> */</p> <pre><code>STAssertTrue([MKStringFromMapRect(rp2) isEqualToString: MKStringFromMapRect(rd)], nil); </code></pre> <p>/*<br> Or should I say almost equivalent... because curiously, the following assertions would fail:<br> */</p> <pre><code>// STAssertEquals(rp2, rd, nil); // Sure, shouldn't compare floats byte-wise! // STAssertTrue(MKMapRectEqualToRect(rp2, rd), nil); </code></pre> <p>/*<br> One would guess they know how to <a href="http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm" rel="nofollow noreferrer">compare floating point numbers</a>, but I digress...<br> */</p> <pre><code>} </code></pre> <hr> <p>This concludes the test function source code.</p> <h2>Displaying Overlay</h2> <p>As mentioned in the question, to debug the problem I've used <code>MKPolygon</code>s to visualize what was going on. It turns out that the two forms of <code>MKMapRect</code>s that span antimeridian are displayed differently when overlayed on the map. When you approach the antimeridian from the west hemisphere, only the one with negative origin gets displayed. Likewise, the positive origin form is displayed when you approach the 180th meridian from the eastern hemisphere. The <code>MKPolygonView</code> does not handle the spanning of 180th meridian for you. You need to adjust the polygon points yourself.</p> <p>This is how to create polygon from the map rect:</p> <pre><code>- (MKPolygon *)polygonFor:(MKMapRect)r { MKMapPoint p1 = r.origin, p2 = r.origin, p3 = r.origin, p4 = r.origin; p2.x += r.size.width; p3.x += r.size.width; p3.y += r.size.height; p4.y += r.size.height; MKMapPoint points[] = {p1, p2, p3, p4}; return [MKPolygon polygonWithPoints:points count:4]; } </code></pre> <p>I have simply used brute force and added the polygon twice—one in each form.</p> <pre><code>for (GGeocodeResult *location in locations) { MKMapRect r = location.mapRect; [self.debugLocationBounds addObject:[self polygonFor:r]]; if (MKMapRectSpans180thMeridian(r)) { r.origin.x -= MKMapSizeWorld.width; [self.debugLocationBounds addObject:[self polygonFor:r]]; } } [self.mapView addOverlays:self.debugLocationBounds]; </code></pre> <p>I hope this helps other souls that wander in to the land of the dragons behind the 180th meridian.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload