mapbox/mbxmapkit

DEPRECATED - Lightweight Mapbox integration with MapKit on iOS

MBXMapKit

MBXMapKit is deprecated in favor of the Mapbox iOS SDK 2.0.0 and above. The future of Mapbox maps is vector rendering, and Apple shows no signs of allowing custom vector rendering in MapKit, so we recommend that you use the OpenGL-based Mapbox iOS SDK 2.0.0 instead.

NOTE: Unlimited, per-user Mapbox pricing plans cannot be used with this version of the Mapbox iOS SDK.

See this doc for the original project details.

mbxmapkit's Issues

Attribution Link?

It looks like Apple's "Legal" link is the only provision for attribution. It doesn't seem like that's enough.

support simplestyle non-points

Builds on #9 support for points.

[VKRasterOverlay setNeedsDisplayInRect:level:] EXC_BAD_ACCESS

Difficult to reproduce, but I has seen a EXC_BAD_ACCESS crash occasionally when I use mbxmapkit. Here is the stack trace. Just wanted to raise the issue incase this is a bug in the mbxmapkit code.

Thread 0: Crashed: com.apple.main-thread
0  libobjc.A.dylib                0x38eb4b66 objc_msgSend + 5
1  VectorKit                      0x36700717 -[VKRasterOverlay setNeedsDisplayInRect:level:] + 134
2  MapKit                         0x2fd5c223 -[MKOverlayRenderer setNeedsDisplayInMapRect:zoomScale:] + 90
3  MapKit                         0x2fd62bdd __50-[MKTileOverlayRenderer canDrawMapRect:zoomScale:]_block_invoke + 144
4  GeoServices                    0x3365b717 ___ZNK49-[GEOTileLoaderInternal _loadedTile:forKey:info:]66__49-[GEOTileLoaderInternal _loadedTile:forKey:info:]_block_invoke3$_1clERKN8LoadItem9RequesterE_block_invoke_2 + 54
5  libdispatch.dylib              0x3939e0c3 _dispatch_call_block_and_release + 10
6  libdispatch.dylib              0x3939e0af _dispatch_client_callout + 22
7  libdispatch.dylib              0x393a09a9 _dispatch_main_queue_callback_4CF + 268
8  CoreFoundation                 0x2eb235b1 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
9  CoreFoundation                 0x2eb21e7d __CFRunLoopRun + 1308
10 CoreFoundation                 0x2ea8c471 CFRunLoopRunSpecific + 524
11 CoreFoundation                 0x2ea8c253 CFRunLoopRunInMode + 106
12 GraphicsServices               0x337c02eb GSEventRunModal + 138
13 UIKit                          0x31341845 UIApplicationMain + 1136
14 Spotsy                         0x000b302f main (main.m:14)

Finish implementing overzooming

Overzooming, or scaling and cropping tiles from a lower zoom level, is useful for:

1. Maps with more than one layer, where the max zoom for one tile source is lower than the max zoom for the other layer. For example, an MBTiles heat map which ends at zoom 10 and a street map which ends at zoom 17. See #20 (comment)
2. Zooming in to distinguish between markers which are close together, or perhaps to see detail in a GPS track. For example, consider a street map which ends at zoom level 16 and markers for two businesses which are only 20 feet apart on the ground. The ability to zoom in to level 17, 18, etc would make it easier to tap on the correct marker.
3. 3D maps which render tiles from a range of zoom levels in perspective on the same map. See #35

I presently have a partial implementation for this (MBTiles on iOS only) over at https://github.com/wsnook/mbxmapkit/tree/issue35. However, that uses image manipulation code that probably won't compile on OS X.

Before this is ready to use, it will need to be adapted to work for online tiles, and it will need to be adapted and tested for OS X.

point CocoaPods docs at mapbox.com

See also CocoaPods/cocoapods.org#23

add ability to toggle between overlay & Apple base

This could maybe be done easily by changing the alpha of the overlay renderer to 0, modifying the canReplaceMapContent to NO, and then reversing the process to bring MapBox back.

/cc @iandundas

Release new Cocoapods version

It's been a long time, and the current Cocoapods release does not work as expected.

Provide notification mechanism for failed TileJSON requests

Per the discussion over at #24, #36, and #61, it seems like probably the best way to download TileJSON is try the request once and send some sort of notification if that request fails. That way the developer who is using MBXMapKit can make their own decisions about whether and how to retry.

One way to do this would be a delegate callback, but NSNotificationCenter (Apple docs, NSHipster) also seems like an attractive option.

Fix marker code for OS X (UIImage vs NSImage)

The marker icon code from pull request #55 (implementing issue #5) includes some UIImage stuff for iOS, but on OS X it needs to use NSImage instead. Something like this ought to fix it:

#if TARGET_OS_IPHONE
    // UIImage stuff
#else
   // NSImage stuff
#endif

bug with custom center on full-world overlays

The problem is how we are conflating the overlay center (midway between the corners) and the starting center as set in the hosted map. We should keep both of these around so that the overlay functionality can work right but we can also center the map on start.

Stop writing things to cache which were just read from cache

As @incanus discovered a bit earlier, there are at least a few places where we're doing something about like this:

// At this point we should have an NSHTTPURLResponse with an HTTP 200, or else an
// NSURLResponse with the contents of a file from cache. Both of those are good.
//
[data writeToFile:makiPinCachePath atomically:YES];

If we got an NSURLResponse by reading the tile/geojson/marker from cache, writing the file back out to cache again 1) is kinda silly, and 2) will update the creation timestamp. Since the current cache sweeping strategy is based on creation times and a cache interval, touching the timestamps on every access is bad.

In places where this is happening, the code should be changed to only write to cache when the response was an NTSTTPURLResponse.

Provide notification mechanism to enable logging of API usage stats

There presently isn't any mechanism to count how many tile requests are coming from MKMapView, how many of those are cache hits, how many are cache misses, how many cache misses get HTTP 200's from mapbox.com, how many get 404's, and so on.

Since API hits cost money, having such a mechanism would allow app developers to allocate the cost of their mapbox.com hosting among end users of their apps, if they wanted to do that.

allow change/animation of overlay alpha

Breakout from #7 (comment)

setVisibleMapRect:... edgePadding requires iPhone Pragma for OSX

Method setVisibleMapRect:(MKMapRect)mapRect edgePadding... requires an iPhone target pragma with a different definition for OSX. (iPhone: UIEdgeInsets, OSX: NSEdgeInsets)

Without the following, mbxmapkit.m would not compile with target OSX:

#if TARGET_OS_IPHONE
- (void)setVisibleMapRect:(MKMapRect)mapRect edgePadding:(UIEdgeInsets)insets animated:(BOOL)animate;
#else
- (void)setVisibleMapRect:(MKMapRect)mapRect edgePadding:(NSEdgeInsets)insets animated:(BOOL)animate;
#endif

add simplestyle support

We should pull down simplestyle JSON for maps and auto-add their points as annotations to the map view.

is MKMapCamera supported?

I'd like to have a MBXMapkit view in perspective, so I tried using a MKMapCamera as I do with the usual MKMapView, but I haven't been able to make it work.

Is this supported or a planned feature? Or is there any workaround to achieve the desired effect?

add API for force refresh of overlay

Assigned to MapBox iOS SDK #2846. As reported in Tender:

Hi,

I use MBXMapKit in an iOS app and have noticed some strange behavior:

1. I put the device in Flight Mode.
   
2. I launch my app and pan to an area that I previously haven't cached tiles for, resulting in the expected checker pattern.
   
3. Disable Flight Mode.
   
4. Now I expect MBXMapKit to get the missing tiles but that doesn't happen. (even if I terminate and launch the app again).

I'm not 100% but I think I actually have to wait for the default 1 week(?) cache to expire for MBXMapKit to fill in the blank tiles.

Thanks!

Wrong cache path when switching mapID.

I'm not sure if you would recommend switching maps by simply setting the mapID to a different value. However, I have found that this works ok apart from tiles that are not yet loaded/cached by the NSURLSession then get stored to the wrong location according to the new mapID. The solution I am using is to store the cachePath to a local variable (with correct mapID) that gets accessed in the NSURLSession's completion handler instead of having it call - (NSString *)cachePathForTilePath:(MKTileOverlayPath)path. Does this seem sensible? Thanks

Can't build OS X sample project

update spec email

ios@ -> mobile@

/cc @geografa

Memory Issue with MBXMapViewTileOverlay?

My app has a view controller for presenting an MBXMapView. The view is defined using a XIB that contains a main view and an MBXMapView-class subview. The MBXMapView view's referencing outlet and delegate are set to the view controller. Here's the view controller's interface:

#import "MBXMapKit.h"
@interface XYZMapViewController : UIViewController <MKMapViewDelegate>
@property (weak, nonatomic) IBOutlet MBXMapView *mapView;
@end

and in the implementation file I set the map view’s mapID in the viewDidLoad method:

- (void)viewDidLoad
{
    [super viewDidLoad];
    self.mapView.mapID = @"justin.map-pgygbwdm";
}

It’s a navigation controller-based app, so I present the map to the user by pushing the map view controller onto the navigation stack. The map correctly appears and displays the online tiles; however, after pushing and popping the controller several times, app memory seems to be accumulating. Monitoring the allocations in Instruments, there are 2 MBXMapViewTileOverlay objects created each time the map view controller is created, one by -[MBXMapView MBXMapView_commonSetupWithMapID:showDefaultBaseLayerMode:] and one by __27-[MBXMapView updateOverlay]_block_invoke_2. When the map view controller is popped and deallocated, the 2 MBXMapViewTileOverlay objects remain in memory. In the code I don’t immediately see what might be holding a strong reference to them. Is this a bug, or am I not creating the map view properly? Thanks!

Tests?

Since this is a minimal new start and we have some freedom, could we write tests? KIF, kiwi and gh-unit look like decent options for ObjC.

0.3.0

Improve sample apps

It would be good to have sample apps which fully demonstrate the capabilities of MBXMapKit in a way which is also usable for convenient regression testing (i.e. something better than the int whichExampleToUse = 0; switch(whichExampleToUse) {... stuff that I included as part of #38).

pay attention to HTTP caching-related headers

Generally, something in cache is better than nothing for a tile if its expiration as stated by the server is not up yet. No need to throw it away if we don't have a fresher one to replace it when the tile is needed again.

Discuss how to re-factor TileOverlay layers

Issue #36 was about whether we should re-factor MBXMapViewTileOverlay and how TileJSON is loaded. It seems like there is some general agreement that we should in fact do that, so this ticket is for discussing how to re-factor. I want to start experimenting with some re-factored code in a new branch, and I need an issue number for it, so that's why I'm making this issue (and for comments, patches, etc once the code is written).

@incanus, I'm expecting for this experiment to be on the quick and dirty side, and that it won't get merged, so I'm going to be a little sloppy about api doc comments in header files and such. If the ideas seem good, I expect to break the work out into issues and smaller commits.

Crash when dismissing map view rendering tiles

I'm seeing a crash when dismissing a view controller displaying a map view that is still in the process of rendering tiles. When I enabled NSZombie, I received the following.

*** -[VKRasterOverlayTileSource invalidateRect:level:]: message sent to deallocated instance 0x1adee910

I had made a few changes to MBXMapView to support initialization with TileJSON, so I backed those out. The problem remained. Since MBXMapView is a subclass, it was trivial to switch to an instance of MKMapKit, which does not exhibit the crash.

Update API docs for for MBTiles (maybe)

The MBTiles fix from #38 exposes MBXMapViewTileOverlay in the MBXMapKit.h header file, which is necessary for MBTiles support to work, and also very helpful for things like manually adjusting the value of an overlay layer's canReplaceMapContent. Presently this is ifdef'ed out, see https://github.com/wsnook/mbxmapkit/blob/dev-0.1.1/MBXMapKit.h#L183-L200, but it might be worth adding to the documentation.

For example, exposing overlay layers in the header file is what makes an easy solution to #7 possible. That problem came about because the current state of the header file is actually obscuring part of the MKMapKit api (direct access to MKTileOverlay objects).

add MBTiles support

This should be straightforward based on RMMBTilesSource. However, linking to SQLite is a problem if we want to keep things simple for installation. Two thoughts right now:

1. For CocoaPods, make MBTiles suppert a subspec. Linking isn't much of a big deal here anyway since it's managed.
2. For manual install, just make a macro at the top of the file to #ifdef out the SQLite code by default. Then, if the dev wants, they can flip the macro bit and link it themselves. This gets around people having to link before use.

Reasons to reconsider async metadata loading design

I think it would be good to re-visit the design of fetching the TileJSON metadata in MBXMapView rather than MBXMapViewTileOverlay. The present design with asynchronous TileJSON loading followed by swapping out the overlay layer seems to be the root cause of several problems including #8, #18, #29, #24, #30, and #33.

There is a lot of code in MBXMapView which seems to be working around the consequences of swapping out the overlay layers after they are created. Moving TileJSON loading to MBXMapViewTileOverlay should make it possible for a whole bunch of code to just go away, which would hopefully make a lot of stuff work more smoothly.

The design I have in mind is...

1. Have the first call to loadTileAtPath:result: trigger an asynchronous load of the TileJSON. Until that is finished, all the calls to loadTileAtPath:result: can just invoke result(nil, error). It might also work to just block those threads until the metadata loads, but I'd hesitate to do that. The main Mapbox iOS SDK has a crashing issue with tile loading because it can create too many blocked threads (mapbox/DEPRECATED-mapbox-ios-sdk#206 ). I don't want to replicate that problem.
2. Step 1 might be all that's necessary, but if not... Add an MKTileOverlayRenderer subclass that uses KVO notifications to keep track of when its associated MBXMapViewTileOverlay has completed loading its TileJSON. Once that happens, it will call its own reloadData method (see https://developer.apple.com/library/ios/documentation/MapKit/Reference/MKTileOverlayRenderer_class/Reference/Reference.html ).

iOS 6 Fallback

I know mbxmapkit has a requirement of iOS 7 because of the API improvements offered in the newest version of iOS, but would it be possible to fall back to Apple's Map Kit if the user still has iOS 6 on their device?

allow proper setting of center/zoom

Similar to the solved overlay ordering issue in 48a02d9, setting a starting center/zoom in the same run loop pass as the init will not take hold as the async post-metadata set will override it.

Pre Download Tiles

Is there any way to pre download certain tiles or deliver the app with a cache to speed up the first app start?

Add an attribution property to all MKTileOverlay subclasses

While providing a complete solution for adding attribution links (see #54) seems like a tricky thing to do for now, it should be pretty easy to get the attribution string from TileJSON or MBTiles metadata and expose that as something like

@property (nonatomic) NSString *attribution;

In the context of #61 (code at mapbox:issue61), that would mean MBXRasterTileOverlay and MBXMBTilesTileOverlay both get an attribution property. From that point it would be up to the developer to decide how to display that string or a suitable equivalent. We could include an example of how to do that in the sample app.

Separate .m and .h files for each class?

At the moment, a whole bunch of stuff is combined into MBXMapKit.m and a partial subset of that is exposed in MBXMapKit.h. For the sake of readability and ease of maintenance, I am in favor of factoring out the individual classes into their own files.

add managed overlay class

We should create an MBXOverlay that abstracts out everything except the mapID required for easy MapBox overlay management. This can use the built-in proxying delegate tile renderer just like the base map does (which is itself an overlay). Then, use would be something simple like this:

[mapView addOverlay:[[MBXOverlay alloc] initWithMapID:@"justin.favespots"]];

add MapBox marker support

Similar to our custom RMMarker stuff we should make it easy to add MBXPointAnnotation objects to the map that tie into Maki.

MBXPointAnnotation *pin = [MBXPointAnnotation new];
pin.coordinate = someCoordinate;
pin.pinImageID = @"bus";
pin.pinColor = [UIColor purpleColor];
[mapView addAnnotation:pin];

Black area when using 3D maps

When using MKMapCamera to enable the 3D mode of the map, some areas are shown black: https://www.dropbox.com/s/l12tcgm5018kif7/Screenshot%202014-02-06%2023.10.59.png

This is due to trying to load a tile with the zoom level of 20 or great. Is there any way to get a lower quality image instead?

What I tried

• Maximum zoom level by listening to map events: Does not work properly due to the 3D mode
• Call the completion block of -loadTileAtPath:result: with nil and error, which results in a white space instead
• Don't call the completion block at at, which results in a white space

I guess it would be possible to calculate the x and y coordinate of the tile of the previous zoom level, which might be complicated and expensive for the device?

sweepCache appears to ignore _cacheInterval

I just noticed that sweepCache includes this stuff (note the kMBXMapViewCacheInterval)

if (attributes[NSFileType] == NSFileTypeRegular && [attributes[NSFileModificationDate] timeIntervalSinceDate:[NSDate date]] < -kMBXMapViewCacheInterval)
    [[NSFileManager defaultManager] removeItemAtPath:filePath error:nil];

and that appears to be ignoring any value for _cacheInterval which might have been previously set by this:

- (void)setCacheInterval:(NSTimeInterval)cacheInterval
{
    _cacheInterval = cacheInterval;
    [self.tileOverlay sweepCache];
}

If I'm reading this right, the present state of things is that the cache interval is always determined in MBXMapKit.h MBXMapKit.m by #define kMBXMapViewCacheInterval 60 * 60 * 24 * 7

investigate NSURLCache

We should look into the use of NSURLCache, possibly with memory-based but definitely with disk-based caching instead of the disk-based, manually-managed caching we have now.

Both NSURLConnection (implicitly, through the use of NSURLRequest behavior and delegate callbacks) and NSURLSession (through a singleton setter) work with this API.

The API also allows easy use of multiple caches with the use of varying disk paths (see -[NSURLCache initWithMemoryCapacity:diskCapacity:diskPath:]) and removal based on NSURLRequest. For the latter, we'd need some code to translate between MKTileOverlayPath and NSURLRequest, but I think in the end we'd have a much simpler system. What we learn could be applied to the SDK as well as future work.

I don't think there's a good reason to use SQLite as we do in the SDK given threading and contention issues likely involved. Disk-based is probably the way to keep things.

Related: #46 #63 #66

Add TileJSON initializer for offline support

We're moving to MBXMapKit from RMMapKit. One thing missing is the ability to initialize an instance of MBXMapKit with TileJSON for offline use with a tile delegate.

Something to the effect of:

- (id)initWithFrame:(CGRect)frame tileJSON:(NSString*)tileJSON;

Inconsistency between initWithFrame and initWithCoder

This may be intended, but an explanation on why would help me out tremulously.

When I init an MBXMapView from code:

    mapView = [[MBXMapView alloc] initWithFrame:self.view.frame];

I can see the default apple map, which is perfect cause at this point I have not added any tile overlays.

However if I add the MBXMapView in a storyboard the initWithCoder method is called. It then does:

    [self MBXMapView_commonSetupWithMapID:nil showDefaultBaseLayerMode:MBXMapViewShowDefaultBaseLayerNever];

The call uses 'MBXMapViewShowDefaultBaseLayerNever' which then adds a blank overlay on top of the apple maps.

Why is that the default behavior? If that is intended I guess I would argue that MBXMapView also overrides the initWithFrame method to execute the same code such that storyboard init and non-storyboard init both work the same.

Big question is why add a blank overlay by default?

move to deterministic host subdomain

Similar to Leaflet, we should move to a deterministic method of picking the a-d subdomain used to optimize cache hits.

Leaflet:

https://github.com/Leaflet/Leaflet/blob/master/src/layer/tile/TileLayer.js#L496-L499

Our current (random) method:

mbxmapkit/MBXMapKit.m

Line 158 in 48a02d9

[@[ @"a", @"b", @"c", @"d" ] objectAtIndex:(rand() % 4)],

OS X testing for pull request #38

Make sure that the MBTiles, Maki marker and tile caching changes from #38 don't break on OS X. Note that in the pull request, most of that code is ifdef'ed out, so it will need to be enabled for testing.

Discuss download manager for offline caching

Should we implement a download manager which automates the process of caching all the tiles within a bounding box? How would that work? Would it be enough if the only API calls are "cache all the tiles in {MKCoordinateRegion} for {mapID}" and "clear the cache for {mapID}", or does it need to support multiple separate, and possibly overlapping, regions in order to be useful? The first case seems pretty reasonable, but the second one might take a lot of work.

For some context, see MBXCacheManager from issue #61 (the code is here).

/cc @radven @kontextbewusst

Add marker geoJSON to the sample map (for #38)

Breaking out the marker geoJSON thing from #38 (comment)...

The simplestyle Maki marker stuff that's part of #38 is currently pointing at a sample map on my Mapbox account because Justin's sample map didn't include any markers at the time I was working on that feature. The fix is to add some markers to the sample map and change the map ID (see https://github.com/wsnook/mbxmapkit/blob/dev-0.1.1/Sample%20Project/MBXMapKit-iOS/MBXViewController.m#L85 )

Here's a copy of the geoJSON from my map:

{"features":[{"geometry":{"coordinates":[-77.06801354885101,38.88279856154733],"type":"Point"},"properties":{"description":"medium, cemetery, #3ca0d3","id":"marker-hqe4si7d1","marker-color":"#3ca0d3","marker-size":"medium","marker-symbol":"cemetery","title":"Arlington National Cemetery"},"type":"Feature"},{"geometry":{"coordinates":[-77.03511625528336,38.889444088524236],"type":"Point"},"properties":{"description":"large, monument, #f86767","id":"marker-hqe4w1mc2","marker-color":"#f86767","marker-size":"large","marker-symbol":"monument","title":"Washington Monument"},"type":"Feature"},{"geometry":{"coordinates":[-77.07225948572159,38.90761328831593],"type":"Point"},"properties":{"description":"small, college, #1087bf","id":"marker-hqe53v134","marker-color":"#1087bf","marker-size":"small","marker-symbol":"college","title":"GWU"},"type":"Feature"},{"geometry":{"coordinates":[[[-77.05782651901245,38.92896825930916],[-77.04956531524658,38.934176119230564],[-77.04244136810303,38.9251455803344],[-77.05782651901245,38.92896825930916]]],"type":"Polygon"},"properties":{"description":"It's a zoo.","fill":"#1087bf","fill-opacity":0.2,"id":"marker-hqewb1jl0","stroke":"#1087bf","stroke-opacity":1,"stroke-width":4,"title":"National Zoo"},"type":"Feature"}],"id":"wsnook.h0bg05jd","type":"FeatureCollection"}

That includes some markers in Washington DC plus a polygon to prove that the parser doesn't misbehave for things which are not points.

Custom Annotations in v0.2.0

I'm trying to use the viewForAnnotation delegate method to customize my map annotations with MBXMapKit v0.2.0 and it is not working. It worked in v0.1.0.

- (MKAnnotationView *)mapView:(MKMapView *)map viewForAnnotation:(id <MKAnnotation>)annotation

never gets called even though it is part of my MKMapViewDelegate.

Let me know if you need additional info, or if there is an example that I should refer to.

Crashes when adding an overlay

Hi,

I want to draw a route on the map and when I return an instance of MKPolylineRenderer in the - (MKOverlayRenderer *)mapView:(MKMapView *)mapView rendererForOverlay:(id < MKOverlay >)overlay method my app crashes.

If I use a normal MKMapView the same code works.

Have attached the log output:

add UTFGrid interactivity support

This can borrow heavily from RMInteractiveSource and just needs a custom gesture recognizer added for non-annotation taps.

Infinite failing TileJSON requests when app launches in airplane mode

If you launch an MBXMapKit app for the first time with airplane mode enabled, it will show an empty map grid and give a steady stream of log messages like this:

2014-01-21 22:53:33.063 MBXMapKit iOS[12416:5503] Error parsing TileJSON for map ID justin.map-pgygbwdm - retrying! (Error Domain=NSCocoaErrorDomain Code=3840 "The operation couldn’t be completed. (Cocoa error 3840.)" (No value.) UserInfo=0x9af85f0 {NSDebugDescription=No value.})
2014-01-21 22:53:33.066 MBXMapKit iOS[12416:1303] Error parsing TileJSON for map ID justin.map-pgygbwdm - retrying! (Error Domain=NSCocoaErrorDomain Code=3840 "The operation couldn’t be completed. (Cocoa error 3840.)" (No value.) UserInfo=0xb8568b0 {NSDebugDescription=No value.})
2014-01-21 22:53:33.069 MBXMapKit iOS[12416:7623] Error parsing TileJSON for map ID justin.map-pgygbwdm - retrying! (Error Domain=NSCocoaErrorDomain Code=3840 "The operation couldn’t be completed. (Cocoa error 3840.)" (No value.) UserInfo=0x1326cef0 {NSDebugDescription=No value.})

This is happening because updateOverlay in MBXMapView includes this stuff:

    else
    {
        NSLog(@"Error parsing TileJSON for map ID %@ - retrying! (%@)", _mapID, parseError);

        [weakSelf updateOverlay];
    }
}
else
{
    NSLog(@"Error downloading TileJSON for map ID %@ - retrying! (%@)", _mapID, error);

    [weakSelf updateOverlay];
}

It seems to me that the ideal way to handle this would be to attempt downloading the TileJSON for a map id only one time, and if that fails, there should be a delegate callback to announce the error. That would give the app an opportunity to retry, display an error dialog about network connectivity, etc.