Discuss how to re-factor TileOverlay layers about mbxmapkit

[incanus]

Sounds great.

I just accidentally realized something kinda interesting...

To my great surprise, my last commit actually loads tiles for the sample map, but it isn't even parsing TileJSON yet, or doing any of the associated notification stuff. What I realized is that as soon as you know the mapID, you can immediately begin downloading tiles, because the url is predictable. Sure you potentially need to change the zoom and centering once the tileJSON is available, but there's no need to worry about any special mechanism to reload the tiles. See #36 (comment)

[incanus]

That's the whole point though -- you don't know whether the layer has full-world coverage or not until you get the TileJSON. That affects the toggling of canReplaceMapContent and reloading as fallout of that.

I think it will be a lot easier to discuss the advantages and disadvantages of making different assumptions around that stuff once I've got a sample app which allows side by side comparisons of many ways of configuring TileOverlays. With a couple more days of banging on this stuff, you should be able to see what I mean in code instead of me just talking about it.

For the specific issue you just mentioned, it's relatively straightforward to configure a different type of behavior.

[incanus]

Cool, that works for me.

[incanus]

Per chat: maybe we just assume full coverage, let the user override with the BOOL argument we have now, but get loading without waiting for TileJSON in the default case by piecing together tile URLs. There are two cases that I want to avoid:

• Adding an alpha transparent and/or regional overlay as above does not show Apple's map underneath, losing context, and
• Adding a full coverage map loads Apple's maps underneath, making for a poor-looking experience and increased overhead

The solutions don't have to be automatic, necessarily.

[incanus]

Third thing we don't want:

• A regional coverage map not knowing its proper bounds and the overlay system constantly requesting tiles which will never exist on the server.

Some notes from chat regarding the screenshot above...

To get that, I changed viewDidLoad in my new sample app from this,

_rasterOverlay = [[MBXRasterTileOverlay alloc] init];
_rasterOverlay.mapID = @"examples.map-pgygbwdm";
[_rasterOverlay addObserver:self forKeyPath:@"center" options:NSKeyValueObservingOptionNew context:nil];
[_rasterOverlay addObserver:self forKeyPath:@"centerZoom" options:NSKeyValueObservingOptionNew context:nil];
[_mapView addOverlay:_rasterOverlay];
_mapView.delegate = self;

to this,

_rasterOverlay = [[MBXRasterTileOverlay alloc] init];
_rasterOverlay.mapID = @"{a map ID for a transparent regional overlay in PDX}";
_rasterOverlay.canReplaceMapContent = NO;
[_rasterOverlay addObserver:self forKeyPath:@"center" options:NSKeyValueObservingOptionNew context:nil];
[_rasterOverlay addObserver:self forKeyPath:@"centerZoom" options:NSKeyValueObservingOptionNew context:nil];
[_mapView addOverlay:_rasterOverlay];
_mapView.delegate = self;

It looks great, and performs fine, but, because the MBXTileOverlay is currently doing this,

- (MKMapRect)boundingMapRect
{
    return MKMapRectWorld;
}

it's generating a bunch of 404's in the background for tiles that aren't in the transparent overlay. To fix that, the bounds from the TileJSON need to be taken into consideration.

[incanus]

Per chat, outlining every scenario that I can think of and that the current version covers in some way. These are all various uses of mapID on our hosting and should be covered, but perhaps automatic detection of each isn't the best route.

By Constraints below, I mean that the app developer could wish for a layer only to be used in a region or zoom range and disallow panning and/or zooming, or they could allow free use, depending upon app design.

• OSM basemap: examples.map-pgygbwdm
  • Coverage: global
  • Transparency: no
  • Apple basemap: never
  • Constraints: N/A
  • Notes: A full-world map that should never load Apple underneath.
• OSM overlay: justin.map-9tlo4knw
  • Coverage: global
  • Transparency: yes
  • Apple basemap: always (example: satellite)
  • Constraints: N/A
  • Notes: A full-world labels map that should always load Apple underneath for context.
• OSM basemap: justin.map-mf07hryq
  • Coverage: global
  • Transparency: no
  • Apple basemap: always (example: labels)
  • Constraints: N/A
  • Notes: A full-world terrain map that should go at MKOverlayLevelAboveRoads and use Apple's labeling.
• TileMill basemap (constrained): justin.NACIS2012
  • Coverage: regional
  • Transparency: no
  • Apple basemap: never
  • Constraints: regional
  • Notes: Dev constrains the app to the basemap's coverage range. Apple should never be loaded since this is the app's basemap.
• TileMill basemap (unconstrained): justin.clp-2011-11-03-1200
  • Coverage: regional
  • Transparency: no
  • Apple basemap: always
  • Constraints: none
  • Notes: Dev does not constrain the basemap, so Apple should always load underneath so that areas of out bounds/zoom of this basemap still show a map.
• TileMill overlay: justin.pdx_meters
  • Coverage: regional
  • Transparency: yes
  • Apple basemap: always
  • Constraints: N/A
  • Notes: Point overlay always needs Apple for context. Note that in this project, I have added an OSM basemap in the online version for context, but the tiles that come down for the overlay have transparency and no basemap.

Oh wow, that's amazingly helpful. Perfect.

On the subject of

Constraints: regional

after looking at the issue for the past hour or so, I'm pretty sure that there is no reasonable way to do that using the MKMapKit api. It offers the ability to set the region which is presently displayed, but as far as I can tell there aren't any properties related to imposing limits on scrolling and zooming other than totally turning them off.

The effect of properly configuring MKTileOverlay's - boundingMapRect, minimumZ, and maximumZ is to cut down on calls to loadTileAtPath:result: which reduces (but doesn't eliminate) 404's. As usual it's possible I'm confused or overlooking something, but I've banged on this quite a bit, and nothing I've seen so far seems to provide any sane way of imposing any limits on scroll/zoom. Besides today, I'm thinking back on some the tests and experimenting I did for the overzooming stuff (#42, #35, and #20).

[incanus]

as far as I can tell there aren't any properties related to imposing limits on scrolling and zooming other than totally turning them off.

I think you're right here -- sorry to not clarify. I meant to say that suppose the user wants to show a view of exactly that size with panning disabled? Constrained by way of not allowing interaction.

which reduces (but doesn't eliminate) 404's

Why doesn't it eliminate? That seems odd. Even in the case of #35 the map view should know that the tiles won't be there.

I meant to say that suppose the user wants to show a view of exactly that size with panning disabled? Constrained by way of not allowing interaction.

That's what I understood you to mean, and I don't think it's possible to do that short of turning off the MKMapView's gesture recognizers an implementing your own with some sort of bounds checking. Apple basically gives you on/off switches for pan and zoom, but that's it. If you want to turn theirs off, you can, and you can supposedly still programmatically adjust the visible region, but Apple doesn't do any of the heavy lifting for making that happen.

Why doesn't it eliminate? That seems odd.

Wish I knew... not enough time in the day to implement everybody's hopes and dreams perhaps.

I've been experimenting with returning a properly calculated MKMapRect from MKTileOverlay's boundingMapRect, and it just seems to introduce glitchyness and random behavior. I'm seriously starting to think that the best solution is to just return MKMapRectWorld -- that's consistent with conclusions I remember reaching previously on other projects about boundingMapRect.

Basically my take is that a few handfuls of 404's are way better than overlays failing to render consistently, crashes, or other flakey stuff of the sort I've been seeing in my experiments this afternoon. 404's are pretty much invisible to users, and if they are really concerned about bandwidth usage, they probably won't be spending much time in mapping apps. Trying to avoid 404's at the expense of glaring visual mis-behavior seems like a losing fight.

reading that again, I didn't understand you... oops
yes, exactly that size with no pan/zoom is possible and easy.

[incanus]

Apple basically gives you on/off switches for pan and zoom, but that's it.

And that's what I mean. Say you are showing a non-interactive map view at the top of a view controller that programmatically changes its center as you scroll through a table view below. The map is always at the top of the screen. In all cases, the points that you are iterating through are in your regional coverage, but in no case do you want Apple maps to load underneath. You always cover your regional area and there is no chance of the user panning outside of that region.

Basically my take is that a few handfuls of 404's are way better than overlays failing to render consistently, crashes, or other flakey stuff of the sort I've been seeing in my experiments this afternoon.

Ok, if that's what it looks like, 👍

Cool I think we're on the same page. My latest commit has demos for all of the scenarios you outlined, more or less behaving as you described. The Connecticut Light & Power one looks a little goofy, but I don't think there's much that can be done about it if you want the Apple map to show underneath. The 404 vs. massive visual glitching thing is kind of an issue there. Believe it or not, the current arrangement for that map looks better than what happens if you try to set a boundingMapRect on that overlay layer.

Aside from that one though, the rest are nice. Mount Hood in particular looks really good.

@incanus, This is about ready for you to have a look (code). I added simplestyle and markers tonight, so now its feature set is pretty much on par with the 0.2.0 milestone code in mapbox:master. The notable exceptions to that are: 1) a considerably fancier iOS demo app, and 2) no demo app yet for OS X.

@boundsj, This might also be of interest to you in relation to #64 (comment). I set up both the tileJSON notification and adding of markers to use delegate callbacks (setting the mapIDs initiates a downloading and parsing of JSON, and when those done, the view controller's delegate protocol methods get invoked on the main thread).

@incanus I just came up with an idea in my last commit (MBXStandardDelegate) which seems like it provides a very clean way of sidestepping the whole delegate-proxying vs. tons-of-viewcontroller-boilerplate problem.

As I was starting the OS X demo, I realized I could make a class like this:

@interface MBXStandardDelegate : NSObject <MKMapViewDelegate, 
            MBXRasterTileOverlayDelegate, MBXSimplestyleDelegate>
@property (weak,nonatomic) MKMapView *mapView;
@end

and then use it in both the Mac app's app delegate and the iOS app's viewDidLoad like this:

    _standardDelegate = [[MBXStandardDelegate alloc] init];
    _standardDelegate.mapView = _mapView;
    _mapView.delegate = _standardDelegate;

    _rasterOverlay = [[MBXRasterTileOverlay alloc] init];
    _rasterOverlay.delegate = _standardDelegate;
    _rasterOverlay.mapID = @"examples.map-pgygbwdm";

    _simplestyle = [[MBXSimplestyle alloc] init];
    _simplestyle.delegate = _standardDelegate;
    _simplestyle.mapID = @"examples.map-pgygbwdm";

[incanus]

Specific to the issue61 branch, I just opened #71 above so we have a place to discuss those particulars.

I'm closing this in favor of #73 because it seems like the general approach of the issue61 branch is sound, but now we need to figure out how to package it well behind a clean API.